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