On 1/21/2014 7:50 PM, Scott Brim wrote:
On Tue, Jan 21, 2014 at 8:07 PM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
On 1/14/2014 7:23 AM, Joel M. Halpern wrote:
Isn't that basically the problem of the inner traffic sender, not the
problem of the tunnel that is carrying the traffic?
Asking tunnel's to solve the problem of applications with undesirable
behavior seems backwards.
By that argument, apps using TCP shouldn't expect the transport to control
congestion. They ought to control it at the app layer.
Tunneled MPLS, when encapsulated inside UDP, *is* the "application". UDP
expects the app to deal with congestion, so it's entirely reasonable for UDP
to expect the tunneling system to do this.
Joe, I believe you are confusing a protocol with an architectural
function.
http://www.isi.edu/rna ought to clear that misconception up.
It's a UDP encapsulation, but that encapsulation has nothing
to do with transport, and what runs over it is not an "application".
That would be correct if the 8-byte UDP header were interpreted anywhere
*except* the current Internet as the demuxing layer above IP. But that
semantics is exactly what this document seeks - to use that UDP
information for load balancing, e.g.
Consider this from the Internet's viewpoint; UDP traffic is traversing
it, sourced by the tunnel ingress, and travels through the Internet with
the congestion control expectations outlined in RFC5405.
To the Internet, this UDP header is a transport layer, and the tunnel
ingress is the application.
Yes, if you were just using these bytes somewhere else, interpreted by
some other mechanism (or not), they'd be just bytes of encapsulation.
But in the Internet, the roles are determined by RFC768, RFC1122, and
RFC5405.
It may be a client layer (with the encapsulation a service layer), but
that's a relative relationship, not an absolution one about stack
position.
In an arbitrary environment, without knowledge of any of the other
protocol layers, yes (that's the principle behind RNA, above).
When instantiated inside the Internet, when you take a physical signal,
interpret it as a link layer packet, examine the next 20-40 bytes as the
IP header, and the next 8 as UDP, then that UDP header *is* the
transport layer for that network (the Internet), and the application
layer *is* whatever generated the contents of that packet (the
encapsulator).
> This instance of UDP is way below transport, is just in
fact a bit of lubrication for the packet, and considered
That's true from the perspective of the MPLS packet and its origin
network, but not from the perspective of the network the UDP
encapsulated result traverses.
_functionally_ has nothing to do with congestion control.
Oh, sure - UDP has nothing to do with congestion control. But that's
exactly why the transport area generated RFC5405's section 3.1.3 -
requiring that the application (the party that generates the UDP
packets) includes congestion control (directly, or by transitive closure
of the source of the source of the source... that generated the original
highest layer of packet, which eventually became encapsulated in UDP).
> The only
reason for using UDP encapsulation is to get through middleboxes. If
something else worked better for that, they would use it.
According to the doc, this is also for load distribution. That aside,
however, it'd be nice if there were a layer that just "got through
middleboxes" and had no other properties.
UDP isn't that layer. Nor is TCP.
TCP comes with its own baggage (including reactive congestion control)
of a heavyweight mechanism that isn't desired for most high-speed tunnels.
UDP comes with RFC5405. That requires some sort of congestion reaction.
No need to be on the same timescale as TCP - it could be much slower, or
could simply be (as Lars suggested) a throttle-limit (circuit breaker).
Joe