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

[Scott Brim <[e-mail]>]

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. It's a UDP encapsulation, but that encapsulation has nothing
to do with transport, and what runs over it is not an "application".
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.  This instance of UDP is way below transport, is just in
fact a bit of lubrication for the packet, and considered
_functionally_ has nothing to do with congestion control. The only
reason for using UDP encapsulation is to get through middleboxes. If
something else worked better for that, they would use it.