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

["Joel M. Halpern" <[e-mail]>]

So a customer buys an Ethernet service from an operator.  And it is 
delivered via MPLS.  Possibly across some other operators (Internet as a 
Service.)
If it is tunneled in IP, or GRE (with or without MPLS), then that is fine.
But if I add a UDP header I must suddenly add congestion control at the 
point I add the UDP header?

I can understand (disagree with, but understand) Llyod's argument that 
the UDP header may reach a host, so the checksum might be an issue.  I 
think taht is dealt with by the fact that the host will drop packets 
with 0 UDP checksums.  But I understand the increased reach concern there.

For congestion control?  Adding an in-network control loop?  When the 
UDP encapsulator may not even know what the service is being used for? 
And so is probably more likely to apply an inner congestion control to a 
TCP stream running over IP over Ethernet over MPLS over UDP as to some 
unconstrained flow?

Yours,
Joel

On 1/14/14 10:29 AM, Eggert, Lars wrote:
> Hi,
>
> On 2014-1-14, at 16:23, Joel M. Halpern <[e-mail]> wrote:
>> Isn't that basically the problem of the inner traffic sender, not the problem of the tunnel that is carrying the traffic?
>
> no, because the sender of the inner traffic may be blasting some L2 traffic, for an L2 where that is OK behavior. But that traffic is now being encapsulated inside UDP and can hence go anywhere on the net *without the sender being aware of this*.
>
>> Asking tunnel's to solve the problem of applications with undesirable behavior seems backwards.
>
> It is the *tunnel* that performs the encapsulation and allows that traffic to go places it couldn't before. And so it's the tunnel's responsibility to make sure that the traffic it injects into the Internet complies with the BCPs we have on congestion control.
>
> Lars
>