[e2e] Fw: IAB Draft on the End to End Principle

[David P. Reed]

That the design "choice" of CC mechanisms is made at the ends need not mean 
that the implementation burden lie on the application designer.   What the 
end-to-end idea does is place choices in the end-app-designer and 
end-user's hands, rather than building a particular choice into the network.

Thus, Michael's argument is entirely consistent with the end-to-end principle.

The deeper issue is that of individual versus collective 
responsibility.   Congestion only arises out of collective behavior, 
interactions among disparate applications.

The end-to-end principle does NOT argue that each end *in isolation* is the 
best place to make all decisions - that would be ridiculous just as the 
pure "libertarian" position is ridiculous in economics - there needs to be 
signalling and cooperation among the sharers of network capacity.

What the end-to-end principle says about collective action is that the 
function implementation should not be centered in the network, because the 
network has no clue whatsoever as to what knobs and levers the applications 
have to control congestion.   (I would normally throw in an example here, 
because the router guys always seem to claim they know everything that 
applications do, but by now it's clear to nearly everyone that the router 
guys only focus on FTP and isochronous streams, neither of which actually 
matter, but make great benchmarks to show off to their customers who also 
don't know what CC makes sense to the real apps out there and yet to be 
invented).

At 10:17 AM 5/21/2003 +0200, Michael Welzl wrote:
>Hi all,
>
>I have a comment about the "protection of innovation" section.
>
>It is definitely correct to some degree ... it justifies the
>end-to-end principle - but while I believe that innovation can
>advance easier when programmability is moved to network end
>nodes, this doesn't necessarily mean that it is good to move
>it totally upward in the stack, to the application layer.
>
>I think that things must be made simple, and should, to a
>degree, be transparent to applications.
>
>An example: moving all the functionality to the application
>would mean that developers of UDP based apps would have to
>implement an appropriate congestion control mechanism
>themselves - this would allow maximum flexibility. And, in
>reality, it leads to hardly any TCP-friendly CC. mechanisms
>being deployed because that's far too complex for something
>that wouldn't necessarily be beneficial for the single
>application in question.
>
>So now we have DCCP, which provides applications with a choice
>of CC mechanisms; it should be easy to use and have a well
>defined interface. This facilitates innovation ("oh, there's
>a new mechanism available in the API, and it's even
>more suitable for my purposes - I'm going to choose this one
>by setting the "init cc" parameter to 3 for version 2 of our
>app").
>
>This, of course, comes at the cost of flexibility, so it's
>always a trade-off ... anyway, I believe that a reasonable
>amount of transparency would mean that:
>
>- an application solely specifies requirements
>
>- an intermediate layer of some kind does its best to organize
>   network resources appropriately (e.g., by choosing the
>   most appropriate congestion control mechanism, setting
>   parameters, adapting packet sizes etc.)
>
>This would make innovation easier: an application would not
>have to be aware of a new (QoS) mechanism, but if there
>was one available and it would be beneficial given the
>app requirements, the intermediate layer could use it.
>So the difficult part would be how to specify requirements
>appropriately ... perhaps as a trade-off ("I'd rather have
>a fluctuating rate than increased loss").
>
>If you're interested, I did a presentation on this idea at
>the GGF7 GHPN-RG and Datransport-RG meetings - the slides are at
>
>http://informatik.uibk.ac.at/users/c70370/research/publications/ggf7-presentation.pdf
>and
>http://informatik.uibk.ac.at/users/c70370/research/publications/ggf7-presentation.pdf
>
>
>Best regards,
>Michael