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

[Michael Welzl]

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