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

[Xuxiaohu <[e-mail]>]

Hi Curtis and Joel,

Thanks a lot for your detailed comments.

Hi Lars,

I wonder whether the following compromised text for the Congestion Consideration section of this doc is roughly acceptable to you.

Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels", the congestion control guidelines for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, MPLS can carry a number of different protocols as payloads. When the MPLS payload traffic is IP-based and congestion-controlled, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. When the MPLS payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled, the UDP tunnel SHOULD employ an appropriate congestion control mechanism which is outside the scope of this document.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Curtis Villamizar [mailto:[e-mail]]
> 发送时间: 2014年1月14日 9:33
> 收件人: Joel M. Halpern
> 抄送: Eggert, Lars; Xuxiaohu; [e-mail]; Scott Brim; IETF
> 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
> in UDP) to Proposed Standard
> 
> 
> In message <[e-mail]>
> "Joel M. Halpern" writes:
> 
> > Lars, are you really asking that the document say:
> > 1) That the UDP encapsulation of MPLS can only be used when the
> > devices performing the encapsulation and decapsulation know what
> > protocol (above IP, if IP is being carried; above Ethernet and IP if
> > the frame is Ethernet carrying IP) is being used
> > 2) That those devices need to engage in a congestion control protocol
> > if the carried packets are not TCP, SCTP, or DCCP?
> >
> > Those both look like excessive and difficult requirements.  Which is
> > fine if our goal is to pretend we are telling folks not to use UDP
> > encapsulation of MPLS.  (I had not thought that was our goal.)
> >
> > In practice, I simply do not see how anyone implementing this will pay
> > any attention to either requirement.
> >
> > Yours,
> > Joel
> 
> 
> Joel,
> 
> I agree that the requirement for the equipment to "know" what is in the MPLS
> traffic is ridiculous.  A provider generally does know whether the traffic will be
> mostly IP or mostly PW and if PW mostly IP inside the PW.
> 
> If stating that implementations SHOULD support a form of congestion control
> satisfies Lars, then its fine to add it.  And then ignore it.
> 
> Even if the document said MUST it is likely to be ignored in practice through a
> non-RFC compliant configuration knob.
> 
> As to whether MPLS tunneled traffic in UDP could end up on the plain old
> Internet, that is exactly what most providers in effect do today with MPLS.  The
> high margin legacy L2 protocols, such as TDM, ATM, FR, all ride on PW and
> MPLS over the very same infrastructure as plain IP.
> The low traffic volume high paying traffic gets queueing priority based on
> paying so much for it and an expectation of good or perfect service and the
> traffic volume is so low that the plain IP traffic doesn't notice.  If a UDP and IP
> header got stuck in there, not much would change.  And certainly any
> congestion control would be disabled.
> 
> If OTOH, some end customer put their NFSv4 over UDP stream or their
> bittorrent stream over MPLS over UDP, it would behave just the same (just as
> badly but no worse) as plain NFSv4 over UDP over IP or plain bittorrent.  No
> change.  And the network hostile bittorrent site isn't going to enable
> congestion control on the UDP tunnel either.
> 
> So this whole discussion is over nothing.  But if putting a SHOULD in a
> document ends the discussion, it might be worth it.  The technical sticky point
> is knowing that the congestion is occuring.  Perhaps a LM like packet on
> another UDP port could be exchanged with the same caveats about inaccuracy
> if implemented in software and inaccuracy if reordering occurs, and a
> recommendation can be made to do something to introduce drop if congestion
> is indicated by this method.  How to introduce drop should be an
> implementation detail, a form of AQM or leaky bucket being possible choices,
> but entirely a local matter.
> Since it is a SHOULD and if no real customer ever wants it we can all just ignore
> it.
> 
> Curtis
> 
> 
> > On 1/13/14 3:50 AM, Eggert, Lars wrote:
> > > 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.
> > >
> > > Lars
> > >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls