Joe, thanks for your response. Comments inline:
On 1/23/2014 1:27 PM, Edward Crabbe wrote:
Part of the point of using UDP is to make use of lowest common
denominator forwarding hardware in introducing entropy to protocols that
lack it ( this is particularly true of the GRE in UDP use case also
under discussion elsewhere).
The tunnel is not the source of the traffic. The _source of the
traffic_ is the source of the traffic.
To the Internet, the tunnel encapusulator is the source of traffic.
Tracing the data back further than that is a mirage at best - and
irrelevant.
The 'internet' cares about characteristics of reactivity to congestion.
This is guaranteed by the /source of the traffic/ independent of any
intermediate node.
The tunnel head-end is responsible for the tunnel walking, talking, and
quaking like a duck (host). When the tunnel head-end knows something about
the ultimate origin of the traffic - whether real, imagined, or from Asgard
- then it has done it's duty (e.g., that it's already congestion
controlled).
But that head end is responsible, regardless of what it knows or doesn't.
And when it doesn't know, the only way to be responsible is to put in its
own reactivity.
This is not fact; it's actually precisely the principle we're currently
arguing about. ;)
I would posit:
The tunnel doesn't have to know anything about congestion or performance
characteristics because the originating application must. See GRE, MPLS,
many other tunnel types, including several existing within the IETF that
make use of an outer UDP header.
The originating application
who's traffic is being tunneled should be responsible for congestion
control, or lack there of.
Perhaps it should be, but that's an agreement between whomever
implements/deploys the tunnel headend and whomever provides the originating
traffic to them. The problem is that this isn't true for the typical use
case for this kind of encapsulation.
How so? As mentioned before, this is the same case as standard GRE/MPLS
etc.
I.e., if we were talking about MPLS traffic that already was reactive, we
wouldn't be claiming the need for additional encapsulator mechanism. It's
precisely because nothing is known about the MPLS traffic that the
encapsulator needs to act.
The MPLS traffic doesn't have to be reactive, it's the applications being
encapsulated / traversing a particular tunnel that are responsible for and
aware of path and congestion charateristics. Because the MPLS head end
knows nothing about the /end to end application 'session'/ characteristics
it /shouldn't/ have anything to do with congestion management.
Are we advocating a return to intermediate
congestion control (I like X.25 as much as the next guy, but...). This
is a very stark change of direction.
I think mandating congestion control is not technically sound from
either a theoretical (violation of end to end principle, stacking of
congestion control algorithms leading to complex and potentially
suboptimal results) or economic perspective (as a very large backbone,
we've been doing just fine without intermediate congestion management
thank you very much, and I have 0 desire to pay for a cost prohibitive,
unnecessary feature in silicon.)
Write that up, and we'll see how it turns out in the IETF. However, right
now, the IETF BCPs do require reactive congestion management of transport
streams.
Which part? The end-to-end principle, or the aversion to congestion
control stacking? These have been implicit in all tunneling protocols
produced by the IETF for the modern internet.
If you don't want/like that, then either don't use transport
encapsulation, or change the BCPs.
These BCPs are defined for an originating /application/. In this case the
UDP header is simply a shim header applied to existing application traffic.
The tunnel head does not introduce traffic independent of the originating
application.
I get Lars comments regarding reach, to some limited extent.
Ultimately, the implication seems to be that the protocols riding the
L2 network will have no form of congestion control and are fundamentally
different than protocols that would reside on a typical wan. I have
some serious doubts about this, although I'm sure this is the case in
some specialized environments. At any rate, it seems to me that a stern
warning regarding edge filtering on interdomain boundaries will be
sufficient.
My concern may be slightly different that his. My concern is that you want
the benefits of a UDP header, but don't like the responsibilities that come
along with it.
Joe