ietf
[Top] [All Lists]

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

2014-01-14 10:13:28
Joel,
You have said (and I fully agree with you) that the UDP encapsulator does not 
even know (in some cases) what the service is for.
If this is the case, how will the UDP encapsulator assign entropy source UDP 
ports to specific MPLS packets it encapsulates without breaking 
reordering-sensitive micro-flows within this service?

Regards,
       Sasha 
Email: Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
Mobile: 054-9266302


-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Joel M. 
Halpern
Sent: Tuesday, January 14, 2014 5:49 PM
To: Eggert, Lars
Cc: mpls(_at_)ietf(_dot_)org; Scott Brim; IETF discussion list
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
MPLS in UDP) to Proposed Standard

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 <jmh(_at_)joelhalpern(_dot_)com> 
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

_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls

<Prev in Thread] Current Thread [Next in Thread>