> -----邮件原件----- > 发件人: Eggert, Lars [mailto:lars@xxxxxxxxxx] > 发送时间: 2014年1月13日 16:50 > 收件人: Xuxiaohu > 抄送: Scott Brim; Joel Halpern; mpls@xxxxxxxx; IETF > 主题: Re: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) > to Proposed Standard > > Hi, > > On 2014-1-13, at 4:40, Xuxiaohu <xuxiaohu@xxxxxxxxxx> 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. > > right, MPLS is the wrong place to address is. The UDP encaps/decaps function > needs to have this functionality. > > >> In any use of UDP, congestion > >> control is either left to something above UDP or ignored (left to > >> queue management). > > There are several cases, see Section 3.1.3 of RFC5405. MPLS-over-UDP can fall > into any of the three cases, depending on what traffic is inside the LSP being > encapsulated. > > You'll notice that RFC5405 for the first case - encapsulation of IP-based > congestion controlled "normal" Internet traffic - even says that the tunnel > SHOULD NOT employ any congestion control scheme of its own. Having layered > control loops fighting is not productive. > > The issue with MPLS-in-UDP (and GRE-in-UDP, and any other encaps scheme > that can carry non-IP traffic) are with cases two and three. When the workload > that is being encapsulated isn't known to be congestion controlled by its > endpoints, it is the obligation of the tunnel to detect congestion and react to it > by reducing the traffic volume. Because for the rest of the network, that tunnel > is the UDP sender, and we have IETF consensus that we don't want UDP senders > that don't react to congestion on the net. (That's one of the main reasons for > the existence of the RMCAT WG - we don't want non-congestion-controlled RTP > media traffic on the net.) > > The key difference between putting MPLS e.g. into IP compared to putting it > into UDP is that once it's in UDP, it can go pretty much anywhere on the net, > because UDP traverses NATs and firewalls much more easily than IP traffic with > a rare protocol number does. > > >> 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. > > Right. However, once you slap a UDP header on a packet during encapsulation, > you now subjected yourself to the rules for Internet UDP senders. Those are > documented in RFC5405, and require the tunnel to implement some sort of > congestion detection and control. I'd personally consider a circuit breaker > mechanism sufficient, like RTP and I think PWE are using. > > > Fully agree. The congestion control should be performed either by the UDP > tunnel itself or the client of MPLS. In the former case, it'd better to specify the > practical congestion control mechanisms (if there were any) in a generic draft > (e.g., RFC5405bis) and then any use of the UDP tunnel could refer to that > generic draft with regard to congestion control. > > The general concept of a circuit breaker is easy enough that it doesn't really > need to be written down. And it wouldn't be possible to describe it in a generic > fashion, because congestion detection is typically specific to the protocol being > encapsulated (e.g., RTP uses RTCP feedback to derive loss information, etc.) And > the reaction to congestion is also dependent on the protocol being > encapsulated (does it support multiple rates or only on/off, what timescales are > OK for reaction, etc.) > > > In the latter case, if the client of MPLS is TCP-friendly, that is great. Otherwise > (e.g., circuit emulation service), it shouldn't be deployed on the Internet at all, > just as has been pointed out in RFC3985, therefore there is no need for any > specific congestion control mechanism on the client. > > > > "... In essence, this requirement states that it is > > not acceptable to deploy an application (using PWE3 or any other > > transport protocol) on the best-effort Internet, which consumes > > bandwidth arbitrarily and does not compete fairly with TCP within an > > order of magnitude." (quoted from Section 6.5 of RFC3985) > > > > The above choice seems no conflict with the following congestion control > guidelines as quoted from Section 3.1.1 of RFC5405, as those non-TCP-friendly > traffic would be transported over a provisioned path, rather than on the > Internet. > > > > "...Finally, some bulk transfer applications may choose not to implement > > any congestion control mechanism and instead rely on transmitting > > across reserved path capacity. This might be an acceptable choice > > for a subset of restricted networking environments, but is by no > > means a safe practice for operation in the Internet." > > How is that in conflict? Both quotes say that Internet traffic needs congestion > control, which is a restatement of RFC2914. Hi Lars, No conflict at all. What I meant is: for those clients of MPLS which are not TCP-friendly (case 2&3 as described in Section 3.1.3 of RFC5405), they should never be transported over the unprovisioned path (e.g., the Internet). Insteads, they should only be transported over a provisioned path in a restricted networking environment. As a result, there is no need for the congestion control mechanism for them. Best regards, Xiaohu > Lars