Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPL

Hi,

On 2014-1-22, at 18:29, Noel Chiappa 
<jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)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).
>
> - 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

signature.asc
Description: Message signed with OpenPGP using GPGMail