<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7235.2">
<TITLE>Re: [1st-mile-nm] Google Policy Blog: response to WSJ articleerrors.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>If the cust has l2 choice then they can get to both L2 and public / open L3 services<BR>
<BR>
If the cust only has L3 then they are locked to the networks available via that L3 provider<BR>
<BR>
I'd extend the model and say that L1 and L2 should be open.<BR>
<BR>
<BR>
--------------------------<BR>
Sent using BlackBerry<BR>
<BR>
<BR>
----- Original Message -----<BR>
From: 1st-mile-nm-bounces@mailman.dcn.org <1st-mile-nm-bounces@mailman.dcn.org><BR>
To: 'John Osmon' <josmon@rigozsaurus.com>; 1st-mile-nm@crank.dcn.davis.ca.us <1st-mile-nm@crank.dcn.davis.ca.us><BR>
Sent: Mon Dec 15 16:49:24 2008<BR>
Subject: Re: [1st-mile-nm] Google Policy Blog: response to WSJ articleerrors.<BR>
<BR>
You raise an interesting issue - is Layer 2 or Layer 3 the right end-user<BR>
interface?<BR>
<BR>
If the Layer 3 1st/last mile network is truly open, there is the prospect of<BR>
a wide range of innovative services (telemedicine, security, etc.)of which<BR>
the customer is free to select any that they choose. If it is layer 2,<BR>
there may be a selection of ISPs, but the customer must select one or the<BR>
other.<BR>
<BR>
This is very roughly analogous to the Cable "Package" versus "Ala Carte"<BR>
debate.<BR>
<BR>
I would like to more thoroughly understand the issues and ramifications, but<BR>
right now I believe I favor a publically owned open Layer 3 network.<BR>
<BR>
Gary<BR>
<BR>
-----Original Message-----<BR>
From: 1st-mile-nm-bounces@mailman.dcn.org<BR>
[<A HREF="mailto:1st-mile-nm-bounces@mailman.dcn.org">mailto:1st-mile-nm-bounces@mailman.dcn.org</A>] On Behalf Of John Osmon<BR>
Sent: Monday, December 15, 2008 11:31 AM<BR>
To: 1st-mile-nm@crank.dcn.davis.ca.us<BR>
Subject: Re: [1st-mile-nm] Google Policy Blog: response to WSJ<BR>
articleerrors.<BR>
<BR>
We need to make sure people aren't fighting the wrong battle. As long<BR>
as people fight for/against net neutrality, it distracts from the real<BR>
issue.<BR>
<BR>
We need neutral first/last mile networks. They should be layer-2<BR>
only, and consumers should be able to choose which ISP that layer-2<BR>
connections hits. Qwest's original DSL model works this way, and<BR>
it was a boon to ISPs and consumers.<BR>
<BR>
Once we have a plethora of ISPs to choose from, we can let each<BR>
ISP do whatever prioritization/caching they want. Since we're free to<BR>
switch between them, we can find one that matches our preferences. <BR>
<BR>
*IF* you assume that the last mile connection also defines your choice<BR>
in ISP, *THEN* network neutrality is an important argument.<BR>
<BR>
Turn the argument around. Fight for a framework where network<BR>
neutrality isn't a requirement.<BR>
<BR>
<BR>
<BR>
On Mon, Dec 15, 2008 at 10:17:25AM -0800, Richard Lowenberg wrote:<BR>
> Net neutrality and the benefits of caching<BR>
><BR>
> <A HREF="http://googlepublicpolicy.blogspot.com/">http://googlepublicpolicy.blogspot.com/</A><BR>
><BR>
> Monday, December 15, 2008 at 12:14 AM<BR>
> Posted by Richard Whitt, Washington Telecom and Media Counsel<BR>
><BR>
> One of the first posts I wrote for this blog last summer tried to define<BR>
what we<BR>
> at Google mean when we talk about the concept of net neutrality.<BR>
><BR>
> Broadband providers -- the on-ramps to the Internet -- should not be<BR>
allowed to<BR>
> prioritize traffic based on the source, ownership or destination of the<BR>
> content. As I noted in that post, broadband providers should have the<BR>
> flexibility to employ network upgrades, such as edge caching. However,<BR>
they<BR>
> shouldn't be able to leverage their unilateral control over consumers'<BR>
> broadband connections to hamper user choice, competition, and innovation.<BR>
Our<BR>
> commitment to that principle of net neutrality remains as strong as ever.<BR>
><BR>
> Some critics have questioned whether improving Web performance through<BR>
edge<BR>
> caching -- temporary storage of frequently accessed data on servers that<BR>
are<BR>
> located close to end users -- violates the concept of network neutrality.<BR>
As I<BR>
> said last summer, this myth -- which unfortunately underlies a confused<BR>
story<BR>
> in Monday's Wall Street Journal -- is based on a misunderstanding of the<BR>
way in<BR>
> which the open Internet works.<BR>
><BR>
> Edge caching is a common practice used by ISPs and application and content<BR>
> providers in order to improve the end user experience. Companies like<BR>
Akamai,<BR>
> Limelight, and Amazon's Cloudfront provide local caching services, and<BR>
> broadband providers typically utilize caching as part of what are known as<BR>
> content distribution networks (CDNs). Google and many other Internet<BR>
companies<BR>
> also deploy servers of their own around the world.<BR>
><BR>
> By bringing YouTube videos and other content physically closer to end<BR>
users,<BR>
> site operators can improve page load times for videos and Web pages. In<BR>
> addition, these solutions help broadband providers by minimizing the need<BR>
to<BR>
> send traffic outside of their networks and reducing congestion on the<BR>
> Internet's backbones. In fact, caching represents one type of innovative<BR>
> network practice encouraged by the open Internet.<BR>
><BR>
> Google has offered to "colocate" caching servers within broadband<BR>
providers' own<BR>
> facilities; this reduces the provider's bandwidth costs since the same<BR>
video<BR>
> wouldn't have to be transmitted multiple times. We've always said that<BR>
> broadband providers can engage in activities like colocation and caching,<BR>
so<BR>
> long as they do so on a non-discriminatory basis.<BR>
><BR>
> All of Google's colocation agreements with ISPs -- which we've done<BR>
through<BR>
> projects called OpenEdge and Google Global Cache -- are non-exclusive,<BR>
meaning<BR>
> any other entity could employ similar arrangements. Also, none of them<BR>
require<BR>
> (or encourage) that Google traffic be treated with higher priority than<BR>
other<BR>
> traffic. In contrast, if broadband providers were to leverage their<BR>
unilateral<BR>
> control over consumers' connections and offer colocation or caching<BR>
services in<BR>
> an anti-competitive fashion, that would threaten the open Internet and the<BR>
> innovation it enables.<BR>
><BR>
> Despite the hyperbolic tone and confused claims in Monday's Journal story,<BR>
I<BR>
> want to be perfectly clear about one thing: Google remains strongly<BR>
committed<BR>
> to the principle of net neutrality, and we will continue to work with<BR>
> policymakers in the years ahead to keep the Internet free and open.<BR>
><BR>
> P.S.: The Journal story also quoted me as characterizing President-elect<BR>
Obama's<BR>
> net neutrality policies as "much less specific than they were before." For<BR>
what<BR>
> it's worth, I don't recall making such a comment, and it seems especially<BR>
odd<BR>
> given that President-elect Obama's supportive stance on network neutrality<BR>
> hasn't changed at all.<BR>
><BR>
><BR>
><BR>
><BR>
> ----------------------------------------------------------------<BR>
> This message was sent using IMP, the Internet Messaging Program.<BR>
> _______________________________________________<BR>
> 1st-mile-nm mailing list<BR>
> 1st-mile-nm@mailman.dcn.org<BR>
> <A HREF="http://www2.dcn.org/mailman/listinfo/1st-mile-nm">http://www2.dcn.org/mailman/listinfo/1st-mile-nm</A><BR>
_______________________________________________<BR>
1st-mile-nm mailing list<BR>
1st-mile-nm@mailman.dcn.org<BR>
<A HREF="http://www2.dcn.org/mailman/listinfo/1st-mile-nm">http://www2.dcn.org/mailman/listinfo/1st-mile-nm</A><BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
1st-mile-nm mailing list<BR>
1st-mile-nm@mailman.dcn.org<BR>
<A HREF="http://www2.dcn.org/mailman/listinfo/1st-mile-nm">http://www2.dcn.org/mailman/listinfo/1st-mile-nm</A><BR>
</FONT>
</P>
</BODY>
</HTML>