ietf
[Top] [All Lists]

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

2014-01-14 10:33:49

RFC5405

   However, if the IP traffic in the tunnel is known to not be
   congestion-controlled, additional measures are RECOMMENDED in order
   to limit the impact of the tunneled traffic on other traffic
   sharing the path.

RFC5405

   | for tunnels carrying IP Traffic,                        | 3.1.3   |
   | SHOULD NOT perform congestion control                   |         |
   |                                                         |         |
   | for non-IP tunnels or rate not determined by traffic,   | 3.1.3   |
   | SHOULD perform congestion control                       |         |

RECOMMENDED == SHOULD

IMHO the intended usage of MPLS over UDP, like the widespread usage of
PW, will not be deployed in a situation where congestion control is
applicable and therefore will not be deployed with congestion control.
And nothing bad will happen.  If we want to define an optional
congestion control in MPLS over UDP, that would meet the RFC5405
recommendation above.

Curtis


ps - Keep in mind that even for the case where Ethernet (L2VPN) over
PW over MPLS over UDP over IP over some L2 is run, the thing run over
the L2VPN Ethernet is predominantly IP.


In message <A1F82D9D-F9D0-46C1-B666-0C13DB79A845(_at_)netapp(_dot_)com>
"Eggert, Lars" writes:

--===============1602757442944542782==
Content-Language: en-US
Content-Type: multipart/signed;
        boundary="Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D";
        protocol="application/pgp-signature"; micalg=pgp-sha1

--Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
        charset=GB2312

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.=20

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.
=20
 "... 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)
=20
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.
=20
  "...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

--Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUtOovdZcnpRveo1xAQICtAP+IEcc32eXYdPz7se0PX+ytfYOjHW1ExJt
bF/Wc+1umMc/GXbLL9tf8fKJdSpe/+ZUhuL6WpYG9BoptbI0uCsWCCH98/WP7BUI
Bzf3SgJE1Qxpv+HNXTtYV1OuKJuYxp4p6Lgujkz1aGtiT1VfpBjX7a5e2D290dCp
Kwtms72DUPw=
=PeLB
-----END PGP SIGNATURE-----

--Apple-Mail=_F966CFC8-CF7E-4540-8EA2-FE7CAF7DBF1D--

--===============1602757442944542782==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls

--===============1602757442944542782==--

<Prev in Thread] Current Thread [Next in Thread>