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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: Eggert, Lars [mailto:[e-mail]]
> 发送时间: 2014年1月13日 16:50
> 收件人: Xuxiaohu
> 抄送: Scott Brim; Joel Halpern; [e-mail]; 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 <[e-mail]> 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