+1
Let the encapsulated transport protocols take care of the congestion
end-to-end.
On Fri, Jan 10, 2014 at 8:32 AM, Scott Brim
<scott(_dot_)brim(_at_)gmail(_dot_)com> wrote:
I don't think it's right to try to solve this in MPLS, because MPLS is
not a forwarding protocol - it's a connectivity protocol. In any use
of UDP, congestion control is either left to something above UDP or
ignored (left to queue management). Similarly, you want the client of
MPLS to be responsible for managing its traffic. MPLS gives you paths,
it doesn't push packets over them.
Scott
On Fri, Jan 10, 2014 at 11:09 AM, Eggert, Lars <lars(_at_)netapp(_dot_)com>
wrote:
Hi,
On 2014-1-10, at 16:36, Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)com>
wrote:
Maybe I am completely missing things, but this looks wrong.
If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion
control will make it more likely that the service won't work. Is that
really the goal?
We do not perform congestion control on MPLS LSPs.
Assuming that a UDP tunnel is carrying just MPLS and was established
just for MPLS, why would we expect it to behave differently than an MPLS
LSP running over the exact same path, carrying the exact same traffic?
we've been rehashing this discussion several times over the years, e.g.,
for PWE, AMT, etc. In order to carry fixed-rate or otherwise
non-congestion-controlled traffic over unprovisioned general Internet
paths, there needs to be some sort of basic congestion control mechanism,
like a circuit breaker.
The whole point of running MPLS is to create networks in which paths are
provisionable, so this is usually not an issue. But if you start sticking
MPLS inside of UDP, those packets can go anywhere on the net, so you need
mechanisms to control the rate of that traffic if it causes congestion, or
at the very least you need to be able to stop the traffic if it creates
severe congestion.
Lars
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls