On Tue, Jan 21, 2014 at 8:07 PM, Joe Touch <touch@xxxxxxx> 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.