From: "Eggert, Lars" <lars@netapp.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
 MPLS in UDP) to Proposed Standard
Thread-Index: AQHPF5eBFyKjVtdEy02x6qUpK40JLJqRjSoA
Date: Wed, 22 Jan 2014 17:55:23 +0000
Message-ID: <64A7AA55-795A-40FA-8008-5FCE3B8E2C44@netapp.com>
References: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu>
In-Reply-To: <20140122172930.3D31A18C13B@mercury.lcs.mit.edu>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/signed;
 boundary="Apple-Mail=_8A1F21FB-58D7-4707-982F-B65299EABE49";
 protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, IETF discussion list <ietf@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
 MPLS in UDP) to Proposed Standard
Precedence: list

--Apple-Mail=_8A1F21FB-58D7-4707-982F-B65299EABE49
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

On 2014-1-22, at 18:29, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> Envision the following 4 (or more) scenarios for one Border Tunneling =
Routing
> (BTR), BTR A, to send packets to another BTR, BTR B, on the path from =
ultimate
> source S (somewhere before BTR A) to destination D (somewhere after =
BTR B).
>=20
> - Plain IP
> - Some existing encapsulation like GRE
> - A new, custom encapsulation
> - Encapsulation using UDP
>=20
> What you seem to be claiming is that in case 4 we need to have =
congestion
> detection and response at the intermediate forwarding node BTR A - but =
it
> would not be required in cases 1-3? This makes no sense.

I'm not saying that. I'm saying that for every tunnel that can extend =
the reach of not-congestion-controlled traffic, e.g., some L2 traffic, =
over the wider Internet, we have a potential problem.

For plain IP as well as encapsulations that use IP protocol numbers that =
are different than UDP, TCP and I guess ICMP, that danger is somewhat =
mitigated, because such traffic typically dies at the next NAT or =
firewall (unless that has been specifically provisioned, which is then =
also OK). So there can be harm, but it will be limited to some segment =
of the network, hopefully the segment that the entity who performed the =
encapsulation manages.

UDP and TCP traverse most NATs and firewalls, if the directionality of =
the flow establishment is as expected by the middlebox ("inside" to =
"outside"). That means that UDP-encapsulated L2 traffic has a much wider =
reach - an Internet-wide reach. That's the fundamental difference to the =
other cases.

> Even better, suppose that BTR A implements _both_ one of the first =
three,
> _and_ UDP encapsulation. If its response to UDP congestion on the path =
to BTR
> B is to.... switch to a _different_ encapsulation for traffic to that
> intermediate forwarding node, one for which it's not required to =
detect and
> respond to congestion, did that really help?

It won't solve the problem, but these other encapsulations have more =
limited reach, and as such the potential for damage is lessened.

> Similarly, if people doing tunnels ditched UDP in favor of some other
> encapsulation (assuming they could find something that would get =
through as
> many filters as UDP does, would have the same load-spreading =
properties that
> UDP does, etc, etc - or maybe not, if that's the price they have to =
pay for
> being free of the grief they are getting because they are using UDP) - =
would
> that do anything at all for any potential congestion from their =
traffic? No,
> it would still be there, obviously.

Depends on the reach of that encapsulation. If it requires manual =
configuration of middleboxes to make it traverse (like GRE would), that =
danger is lessened. If it traversed such middleboxes by default, as UDP =
does, it has the same issues.

> Look, the current architectural model of the Internet for dealing with
> congestion is that the _application endpoints_ have to notice it, and =
slow
> down. Intermediate forwarding nodes don't have any particular =
responsibility
> other than to drop packets if they have too many.

Right. =46rom the viewpoint of the Internet, the *encapsulator* is that =
application endpoint. That's what the whole concept of a tunnel is =
about.

> You are quite right that if we take some application that doesn't =
detect and
> respond to congestion (perhaps because it was written for a local =
environment,
> and some bright spark is tunnelling that L2 protocol over the =
Internet), that
> can cause problems - but that's because we are violating the =
Internet's
> architectural assumption on how/who/where congestion control is done.

Exactly.=20

> I don't have any particularly brilliant suggestions on how to respond =
to
> situations in which applications don't detect and respond to =
congestion.
> Architecturally, if we are to keep to the existing congestion control =
scheme
> (endpoints are responsible), the responsibilty has to go back to the =
ultimate
> source of the traffic somehow...

No, it doesn't. That responsibility lies with the entity that injects =
that packet into the Internet, which is the encapsulator. For the rest =
of the Internet, the encapsulator is the sending application of the UDP =
traffic. Without the encapsulator, that traffic would not exist on the =
Internet.

> But saying that _intermediate forwarding nodes_ have to detect =
down-stream
> congestion, and respond, represents a fundamental change to the =
Internet's
> architecture for congestion control.

And here's the fallacy: UDP encapsulators are forwarding nodes *only* =
from the viewpoint of the final endpoints. =46rom the viewpoint of the =
rest of the Internet, they are traffic *sources*, not *forwarders*.=20

Lars

--Apple-Mail=_8A1F21FB-58D7-4707-982F-B65299EABE49
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-----

iQCVAwUBUuAGCtZcnpRveo1xAQKpqQQAsy2+qTUBiH1uxeE2Z5H2CcqVCmKNEMxf
snsKO+JwL36uQE+GpMUk59FWmQwI8qpOwx5cONDddNfGWcKVdIVRt4IxwNs5XA4/
67oPhuPTMMAHysRw5YgK0wTWitMZQ0iuuogcL2u2x/S3i1VxLIHj5dtP/4+gvedt
QbCu9sKKu6Y=
=EvAi
-----END PGP SIGNATURE-----

--Apple-Mail=_8A1F21FB-58D7-4707-982F-B65299EABE49--