Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Joe Touch <[e-mail]>]

On 1/21/2014 7:50 PM, Scott Brim wrote:
> On Tue, Jan 21, 2014 at 8:07 PM, Joe Touch <[e-mail]> 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