[e2e] Time for a new Internet Protocol

[Bob Briscoe]

David,

At 13:28 22/05/2007, David P. Reed wrote:
>Can tussles be quantified?   In principle if not in practice?   Levers in 
>physics can, which is why I am asking.

The question "what class of players can control a lever?" isn't 
quantitative, but below I point to meagre attempts I've made in the past to 
make this more scientific.

>The reason for asking is to understand whether the "tussle" idea is like 
>the "end to end argument" (which was originally derived from observation 
>of its use in practice, proposed as a general structure for thinking about 
>designs and modularity, not as a quantitative tool, but evolved to become 
>a principle of sorts, and even to be quantified in the language of "real 
>options" by Mark Gaynor, and in other words in the language of "system 
>dynamics" by Charlie Fine's Clockspeed concept).

I have tried to start making the articulation of tussle more exact in my 
own small way. It relates (loosely) to clockspeed actually, tho I hadn't 
seen Charlie's work when I wrote it. My early thoughts on a QoS/congestion 
control example (a tech report actually mostly written in Mar 2002 before 
the tussle paper was published) are here:

Market Managed Multi-service Internet (M3I): Architecture Principles
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#m3i_arch>
In particular section 2.3.3 "Control assumptions in QoS technologies"

A synopsis:
* A protocol allows a party without inherent control to influence the party 
with inherent control.
* Between signals, the party with inherent control is in charge.
* We can place each QoS architecture's assumptions about who is in control 
on this spectrum, based on the time granularity of the protocols (per 
packet, per flow, per SLA etc.)
* and more insights, but you can read them yourself...

* But first the architecture has to be 'designed for tussle', which means 
that the main players in conflict both have access to the same control 
information, with the same timeliness, and both have the /ability/ to 
control some feature (a good example is my own re-feedback, which was of 
course explicitly designed with this intent).

* Then, once either of two conflicting players can take control, outside 
forces can determine what actually happens in different parts of the net at 
different times. Where "outside forces" = market selection, govt 
regulation, social control etc. Altho the paper title is "Market 
Managed..." I was careful to ensure this was not the only option (so Jon's 
concern that not every big country in the world likes markets is catered for).

But, we're actually a long way off an analytical understanding. Unlike the 
e2e principle, the original tussle paper doesn't really even have a good 
concrete example (there are some high level arm-wavy examples, but not 
anything like as concrete as the TCP reliability example in the e2e 
principle paper).

And certainly not enough to be able to guide any debate about what tussles 
are _not_ worth designing the architecture around. Oor how we might trade 
off the cost of allowing for tussle against the benefit it might bring - 
e.g. is it worth the cost to feed end systems routing information so they 
can make source routing choices? Can a cut-down subset serve sufficiently? etc.

To add to Jon's examples, in my original posting to you I gave a link to 
slideware I did back in 2004 to give some case studies.
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0406pgnet>
There's examples of DoS control, message routing systems, QoS and so on in 
there.

Some others I've come across since:
- the choice of link technologies that IP originally enabled (related to 
TV's point about tussles having already taken place below IP)
- SIP end-end vs SIP proxy mode
- IPSec transport vs tunnel mode
- source routing vs router routing
- and so on.

The current Internet architecture has some key parts that I would contend 
aren't designed for tussle:
- only network operators can route (e.g. by preventing end systems seeing 
routing information)
- only end systems can control load (e.g. by hiding path feedback 
information from routers).


>I think it would be great if the tussle concept could migrate from a 
>descriptive term to a term of art or even quantified analysis.  But since 
>I don't understand the term enough to use it correctly in the manner meant 
>by its advocates, I urge them (not just the original authors) to consider it.

We've just put a proposal in to the EU Future Internet call (to get our 
hands on those tax euros Vadim so loves ;), which includes developing 
analytical techniques to be able to assess how well an architecture is 
designed for tussle. And also to learn lessons from the success or 
otherwise of case studies from the past where tussle has intuitively been 
included in a design (or not). And whether/how/why this correlates with 
successful outcomes. So watch this space.


Cheers



Bob

>Jon Crowcroft wrote:
>>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
>>
>>
>>
>
>____________________________________________________________________________
>Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196