-----邮件原件-----
发件人: Eggert, Lars [mailto:lars(_at_)netapp(_dot_)com]
发送时间: 2014年1月13日 16:50
收件人: Xuxiaohu
抄送: Scott Brim; Joel Halpern; mpls(_at_)ietf(_dot_)org; 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(_at_)huawei(_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.
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.