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

["Eggert, Lars" <[e-mail]>]

Hi,

On 2014-1-22, at 18:29, Noel Chiappa <[e-mail]> 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).
> 
> - Plain IP
> - Some existing encapsulation like GRE
> - A new, custom encapsulation
> - Encapsulation using UDP
> 
> 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. From 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. 

> 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. From the viewpoint of the rest of the Internet, they are traffic *sources*, not *forwarders*. 

Lars