[Chapter-delegates] Statement on Open Internet proposal fromGoogle and Verizon

Mon Aug 23 10:36:16 PDT 2010

Fred, 

My comment is that as we get Edge drift (by which I mean power drifts out of the edge) so demand for regulatory input increases to control what goes on in the network. Another way to balance this is for the protocols to do some of that rebalancing work. 

[As you ask. Edge is the bit where the user sits or the user device. It can also be a proxy for the user so your corporate network as an End user Network (EUN) would be the Edge and might require you as the ultimate user to delegate some of your user power to a shared company network policy. But see my point about Goolge as a typical user below]

To give an example. 

IETF seems to be fixated on various tunnelling mechanisms to rebalance problems where stuff in the network gets in the way or can't cope with what the edge wants to do. 

An interesting if extreme example is IRON by Fred Templin out of the IRTF. http://tools.ietf.org/html/draft-templin-iron-10 . Ostensibly to protect routing table expansion where massive increases in multi-homing occurs it proposes tunnelling mechanisms with formation of a structured OverNet infrastructure. 

But I am mindful of http://tools.ietf.org/html/draft-ietf-intarea-tunnels-00 which makes it clear that tunnels are not really an architectural feature of the Internet but rather an ad hoc implementation. Albeit one that could and needs to be formalised. 

to quote from the draft 

5.1. Tunnel model

  The Internet architecture is composed of hosts, gateways (i.e.,
  routers), and links [Cl88]. A host is a source or sink of network
  packet traffic, a router redirects packets from one set of links to
  another, and links interconnect hosts and routers. Although
  originally described for the Internet's network layer, this
  architecture, with a bit of renaming (e.g., routers become bridges),
  applies equally well for link layers.

  Tunnels could, in principle, be related to this basic model in one of
  three ways:

  o  Tunnel as a link

  o  Tunnel as a router/bridge

  o  Tunnel as invisible

Interesting. 

There is a significant problem if IETF is depending on tunnel mechanisms (ad hoc designs) to redress control plane issues at the edge (which it is) but where the use of tunnels is not an intrinsic feature of the Internet connection architecture. At least not technically defined and so by implication not policy defined either. It throws a question mark over how Tunnels could be treated by transit networks and the developing regulatory framework(s) around net neutrality etc.   

So I am hoping that Joe and Mark Townsley's ideas will find some resonance. 

So Tunnels are being used to extend the control plane for the edge across intervening network space. The size of the vanilla control plane that most IETF protocols assume is end to end connectivity. The reality is that your home network vanilla control plane hardly extends into your ISP. 

However Google's network policies extend via its direct global backbone into remote ISP's peering over BGP. They do accept Google advertisements! So you have to (even if you want to) tunnel into Cisco HQ (blast through your ISP regardless) whereas Google gets a vanilla network and ISP peering.  Google OnNET stretches a lot further and deeper than yours (and mine!) This is one dimension of why I question if Google is a typical end user. Yes it is edge more than transit but not typical. 

Christian 

On 14 Aug 2010, at 00:10, Fred Baker wrote:

> It would help me to understand what Christian is asking the IETF to do, and what specifically he might be calling the "edge". IETF protocols are not limited to one or another networking domain, and many of them are in fact used at what I call "the edge", which is to say any network that is not a transit network. In my case, residential broadband, my upstreams are my company via a VPN and my service provider (a Cable Modem carrier in the US) directly, and my home network is the network at the "edge". I could use BGP in it, but don't have any real reason to and my upstreams won't talk with me. My company uses EIGRP internally and therefore my home office participates in that. What other protocols did he have in mind that don't run on my laptop?
> 
> 
> 
> On Aug 13, 2010, at 10:28 AM, Joly MacFie wrote:
> 
>> 
>> These are good questions raised by Christian on Dave Farber's IP list:
>> 
>> From:  Christian de Larrinaga
>> Date: August 13, 2010 
>> 
>> DiffServ and MPLS may or may not be a good thing but if a user is unable to configure and control their network end to end then the control plane is moving into the network. Much of the network is dark to users due to secret or at best opaque peering and transit relationships. 
>> 
>> For that reason alone users are turning to regulators to address the balance. 
>> 
>> In light of this I do think it worth asking if Google is still a typical user? and if the IETF might extend the control plane of its protocols to the edge?
>> 
>> 
>> Christian
>> 
>> Christian de Larrinaga
>> 
>> 
>> On 12 Aug 2010,  Richard Shockey wrote.. 
>> 
>> First .. packet discrimination or application specific packet discrimination of IP networks is a integral part of the Internet Protocol suite and has been since nearly its inception.  First was Differentiated Services or difserv RFC 2474 RFC 2475 etal or wikipedia for details.  Recently the IETF and our cousins at the ITU  has spent huge amounts of brain power defining the architecture of MPLS or Multi Protocol Label Switching for IP which is rapidly ( along with Ethernet) becoming the core of global carrier networks.  Look it up. This is a good thing.  IP has won now us poor engineering grunts have to make it work.  
>> 
>> 
>> 
>> 
>> -- 
>> ---------------------------------------------------------------
>> Joly MacFie  218 565 9365 Skype:punkcast
>> WWWhatsup NYC - http://wwwhatsup.com
>> http://pinstand.com - http://punkcast.com
>> Secretary - ISOC-NY - http://isoc-ny.org
>> ---------------------------------------------------------------
>> 
>> _______________________________________________
>> Chapter-delegates mailing list
>> Chapter-delegates at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/chapter-delegates
> 