[e2e] Time for a new Internet Protocol

Jon Crowcroft Jon.Crowcroft at cl.cam.ac.uk
Tue May 22 02:23:00 PDT 2007


Tussles:

Network architectures have levers that 
interface between the consumer and the producer
and in the internet case, between competitors - 

These levers implement tussles

Some examples of levers:

1. Congestion control is a lever which matches demand and supply on a short time frame, 
while trying to create (however illusory) some notion of fairness/transparency (neutrality?)
as in Frank Kelly's dual model (or the caltech optimization formulation)

2. BGP policy control is a lever that controls ingress/egress/transit and 
create ways for businesses to compete or cooperate (peering or customer/provider)
at the aggregate level (allegedly - of course, many policies are no such thing)

3. Obviously, recursive levers exist such as the interaction between TCP and TE
or the interaction between IGP and BGP (Hot Potatoe versus other policy).

4.  Since levers are coupled (e.g. change of route changes latency, 
and selects different bottlenecks, so changes TCP throughput),
mutual recursion between tussles is obviously a given.

Change the architecture, (e.g. do source routing)
you may change the levers  (allow uses to bypass BGP or TE)
and you may make some tussles collapse (remove possible market) 
or you may improve the market efficiency 
(e.g. by giving more information so that the market operates better)
depending on the details.

Of course all this assumes that a market (in networks) is a good thing
which some people have asserted, but some people may just be (in the words 
of Some Like it Hot) getting too big for their boots...

Some reasons markets are inefficient: 

	information hiding (BGP is good at this, which may be good or bad).
	mismatch in timescales (TE v. TCP)
	cartels (NANOG, anyone?)
	shortages esp. false scarcity (address space is pretty good example)
	over regulation
	under regulation
	etc etc

Some reasons to be cheerful, part 3.

	Most people in the world dont use the internet so there's a big opportunity 
	to build something useful for the 4/5 of the worlds population where 
	all this chat is irrelevant and other things (buildings and food, maybe peace) 
	matter more right now

	Some countries that are quite big dont subscribe to markets being the only way to do things
	and some of the same countries build their own quite good and quite cheap routers (can you say China)

	The weather is quite good and I'm going on vacation...ciao.


In missive <97B67348-C6C7-4065-AEC8-C9DB997F44B4 at pch.net>, Tom Vest typed:

 >>On May 21, 2007, at 9:25 PM, David P. Reed wrote:
 >>
 >>> I'm now completely confused.   Perhaps those who understand the  
 >>> "tussle" principle could tease out these concepts in a way that the  
 >>> rest of us can understand?   A small start would be explaining in  
 >>> what way that "tussle is inherently recursive"?
 >>
 >>Since I just made the idea up, I'll be happy to clarify -- perhaps  
 >>that'll make it easier for others to spot the flaws in my logic.
 >>
 >>The idea is a nested  game, where two tusslers are tussling over the  
 >>exploitation/control of a given interface, the value of which is  
 >>determined by the outcome of a more basic/encompassing game, one in  
 >>which two tusslers are tussling.... repeat ad infinitum.
 >>
 >>Replace the word "game" with your favorite approximation of OSI/ 
 >>protocol stack, and you arrive at what I had in mind.
 >>In fact, the point I was flogging to excess on the list last week was  
 >>an application of this idea/explanatory framework to the origins of  
 >>the Internet, and its relationship to the timing and location of  
 >>telecom regulatory changes (e.g., on 1968, 1976, 1984, 1994, 1996)  
 >>that slowly expanded, and then multiplied, the functional and spatial  
 >>domain within which it was possible, and useful, to provision  
 >>"independent" IP networks, routing blobs, ASes, etc. -- meaning  
 >>operationally independent from each other as well as from the  
 >>underlying telecom facilities owner(s), who previously were the only  
 >>institutions that could make use of the facilities platform.
 >>
 >>Happy to provide more details/illustrations if that would help ;-)
 >>
 >>TV
 >>
 >>
 >>> Tom Vest wrote:
 >>>> Being a big fan and frequent user/abuser of the tussle concept,  
 >>>> let me be the first person to observe some obvious problems that  
 >>>> follow from using it as a normative principle:
 >>>>
 >>>> 1.  Although the concept of tussle is inherently recursive, it's  
 >>>> typically only used (e.g., by network architects and systems  
 >>>> theory people) to discuss the upper elements of the protocol/ 
 >>>> service stack. Too often people forget, or maybe fail to notice,  
 >>>> that the Internet itself only exists in its "current canonical  
 >>>> form" in places when & where a prior/foundational tussle over  
 >>>> control of communications facilities/infrastructure inputs  
 >>>> resulted in certain sorts of outcomes. In places where all or  
 >>>> almost of the interfaces are hidden/controlled by a single  
 >>>> monolithic entity (e.g., like hierarchical/horizontal  
 >>>> infrastructure segments within a territorial monopoly PSTN),  
 >>>> tussle may still exist, but it has approximately zero impact/ 
 >>>> significance to outsiders.
 >>>>
 >>>> 2. As soon as "tusslers" become aware of the idea, they tend to  
 >>>> incorporate it, rhetorically if not operationally, into their  
 >>>> future actions. Granting that I am no game theory expert (and  
 >>>> would love to hear a better informed comparison here), this seems  
 >>>> like just another example of an iterative bargaining game, ala the  
 >>>> Prisoner's Dilemma. An appeal to the reasonableness of a "tussle- 
 >>>> friendly outcome" is just as likely as not to be a gambit to "win"  
 >>>> a larger piece of the pie... unless maybe the appeal is coming  
 >>>> from someone you already trust for some unrelated reason.
 >>>>
 >>>> Bottom line: tussle provides a great descriptive framework for  
 >>>> understanding how, when, and why things change (or don't change),  
 >>>> and would be a fine architectural guide for a monolithic Supreme  
 >>>> Being who has prior knowledge of "what good would be good" to  
 >>>> select as the criteria for winning in any particular tussle  
 >>>> instance -- but as soon as you have two Semi-Supreme Beings they  
 >>>> end up stuck in the same bargaining game described so crudely  
 >>>> above...
 >>>>
 >>>> Regards all,
 >>>>
 >>>> TV
 >>>>
 >>>> On May 21, 2007, at 7:10 PM, Bob Briscoe wrote:
 >>>>
 >>>>> David,
 >>>>>
 >>>>> Going back to your opening posting in this thread...
 >>>>>
 >>>>> At 15:57 15/05/2007, David P. Reed wrote:
 >>>>>> I call for others to join me in constructing the next Internet,  
 >>>>>> not as an extension of the current Internet, because that  
 >>>>>> Internet is corrupted by people who do not value innovation,  
 >>>>>> connectivity, and the ability to absorb new ideas from the user  
 >>>>>> community.
 >>>>>
 >>>>> So, how do we make an Internet that can evolve to meet all sorts  
 >>>>> of future social and economic desires, except it mustn't evolve  
 >>>>> away from David Reed's original desires for it, and it mustn't  
 >>>>> evolve towards the desires of those who invest in it? Tough  
 >>>>> design brief :)
 >>>>>
 >>>>> My sarcasm is only intended to prevent you wasting a lot of years  
 >>>>> of your life on this project, without questioning whether the  
 >>>>> problem is with your aspirations, not with the Internet...
 >>>>>
 >>>>> Perhaps it would help _not_ to think of suppression of innovation  
 >>>>> as a failure. Innovation isn't an end in itself. People don't  
 >>>>> want innovation to the exclusion of all else. People want a  
 >>>>> balance between innovative new stuff and uninterrupted, cheap,  
 >>>>> robust, hassle-free enjoyment of previous innovations.
 >>>>>
 >>>>> Surely the real requirement is for a distributed computing  
 >>>>> internetwork that can be temporarily or locally closed to milk  
 >>>>> the fruits of an innovation without having to be permanently and  
 >>>>> ubiquitously closed. That is, locally open or locally closed by  
 >>>>> policy control. That's a heroic research challenge in its own  
 >>>>> right - and not impossible - here's some case studies that have  
 >>>>> (sometimes unconsciously) achieved this:
 >>>>> <http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0406pgnet>
 >>>>>
 >>>>> A desire to embed _only_ openness into the architecture to the  
 >>>>> exclusion of thinking how to do closedness is the problem, not  
 >>>>> the solution. So, I for one won't be joining you in this venture,  
 >>>>> even though my initial reflex action would be (and always was)  
 >>>>> openness. I'd ask you to reconsider too.
 >>>>>
 >>>>> If you disagree with this 'Tussle in Cyberspace' argument, I  
 >>>>> think you ought to say why, as I've not heard a good argument  
 >>>>> against it.
 >>>>>
 >>>>>
 >>>>>> To save argument, I am not arguing that the IP layer could not  
 >>>>>> evolve.
 >>>>>> I am arguing that the current research community and industry  
 >>>>>> community that support the IP layer *will not* allow it to evolve.
 >>>>>
 >>>>> You don't need to start out deciding that, whatever the solution,  
 >>>>> it won't be an evolution from where we are. That doesn't need to  
 >>>>> be decided until you know what the solution might look like.
 >>>>>
 >>>>>
 >>>>>> But that need not matter.   If necessary, we can do this  
 >>>>>> inefficiently, creating a new class of routers that sit at the  
 >>>>>> edge of the IP network and sit in end user sites.   We can  
 >>>>>> encrypt the traffic, so that the IP monopoly (analogous to the  
 >>>>>> ATT monopoly) cannot tell what our layer is doing, and we can  
 >>>>>> use protocols that are more aggressively defensive since the IP  
 >>>>>> layer has indeed gotten very aggressive in blocking traffic and  
 >>>>>> attempting to prevent user-to-user connectivity.
 >>>>>
 >>>>> If this is what you want you don't need a new Internet. You  
 >>>>> already have the power to encrypt and the power to be  
 >>>>> aggressively defensive with the current Internet (as your TOR and  
 >>>>> Joost examples demonstrate).
 >>>>>
 >>>>> You want to use the infrastructure those nasty routerheads have  
 >>>>> invested in, presumably to benefit from the network effect their  
 >>>>> investments (and your previous inventiveness) helped to create.  
 >>>>> And if they try to stop you, are they not justified? What is the  
 >>>>> difference then between your traffic and an attack - from /their/  
 >>>>> point of view?
 >>>>>
 >>>>> Or are you claiming a higher moral right to abuse the policies  
 >>>>> they impose on their networks because you have honourable  
 >>>>> intentions, in /your/ opinion? Universal connectivity isn't a  
 >>>>> human right that trumps their policies. It's just something you  
 >>>>> (& I) care about a lot. Isn't this getting close to an analogy  
 >>>>> with animal rights activists conspiring to kill vivisectionists.
 >>>>>
 >>>>> Reversing this, what if someone launches a DoS attack against an  
 >>>>> unforeseen vulnerability in your new Internet? Would your  
 >>>>> architecture never allow it to be blocked, because that would  
 >>>>> damage universal connectivity?
 >>>>>
 >>>>> I think you need to take a step back and reconsider the  
 >>>>> aspersions you're casting on routerheads. They understand the  
 >>>>> value of universal connectivity too. But they also understand the  
 >>>>> higher value of some connectivities than others. Given the tools  
 >>>>> they have at their disposal right now, the best they can do is  
 >>>>> block some stuff to keep other stuff going. It's as much the  
 >>>>> fault of you and me that they have no other option, as it is  
 >>>>> their fault for blocking stuff.
 >>>>>
 >>>>> You are blaming operators for acting in their own self-interest.  
 >>>>> Shouldn't you blame the designers of the architecture for not  
 >>>>> expecting operators to act in their own interests? Again, what is  
 >>>>> your argument against 'Tussle  in Cyberspace'?
 >>>>>
 >>>>>
 >>>>> Bob
 >>>>>
 >>>>>
 >>>>>
 >>>>
 >>>>
 >>

 cheers

   jon



More information about the end2end-interest mailing list