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
On 1/13/14 3:50 AM, Eggert, Lars wrote:
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.
Lars