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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+100

the same problem would exist with or without the additional encapsulation (this includes any L2 encaps that may exist in the case of L2 tunelling.)  The only difference is /reach/.  This same concern exists *most* common tunnels types in the internet today.



On Tue, Jan 14, 2014 at 7:23 AM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> 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.

Yours,
Joel


On 1/14/14 10:20 AM, Eggert, Lars wrote:
On 2014-1-14, at 15:20, Stewart Bryant <stbryant@xxxxxxxxx> wrote:
Yes, the inner (real) transport header is the only meaningful place
to apply congestion avoidance.

But what if the inner traffic isn't congestion controlled?

Lars

_______________________________________________
mpls mailing list
mpls@xxxxxxxx
https://www.ietf.org/mailman/listinfo/mpls


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]