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

Hi,

On 2014-1-22, at 19:32, Noel Chiappa 
<jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu> wrote:
> > From: "Eggert, Lars" <lars(_at_)netapp(_dot_)com>
> > Depends on the reach of that encapsulation. .. If it traversed such
> > middleboxes by default, as UDP does, it has the same issues.
> Exactly. The problem is not specific to UDP. So why is the discussion
> (seemingly) trying to solve it in a UDP-specific way?
you conveniently cut the part of my original message where I tried to explain 
that the difference is in *reach* of the traffic.

> I repeat: even if people were _not_ using UDP encapsulations, the exact same
> problem (of potential congestion caused by non-congestion-compliant
> applications) would still exist. Switching to a different encapsulation method
> is not going to get rid of _any_ potential congestion - not one packet's
> worth.
The severity of the problem depends on the reach of the traffic. Encapsulating 
something inside some "obscure" IP protocol number limits the reach. 
Encapsulating in UDP does not.

> So can we just drop all mention of UDP, since it's irrelevant to the _real_
> problem?
But it isn't.

> > > 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*.
> I present two boxes. In one, a packet comes in, and after some manipulation of
> headers, the packet goes out. In the other, a packet comes in, and after some
> header changes, the packet goes out. You're trying to tell me that,
> architecturally, one _is_ an intermediate forwarding node (which doesn't have
> to detect downsteam congestion, and respond), and the other is not (and so
> does have to)?
You have oversimplified the scenario. 

In one case, an L2 packet comes in, and goes out as an L2 packet that is 
limited in reach to the L2 topology, or as an L3 packet with an obscure IP 
protocol number that will make it die at the next middlebox (in the case of 
MPLS in IP).

In the other case, an L2 packet comes in and it comes out as an L4 UDP packet 
that can now go anywhere on the Internet.

Surely you see the difference?

> And I repeat: mandating that nodes which are forwarding nodes have to detect,
> and respond to, downsteam congestion caused by non-congestion-compliant
> traffic flowing _through_ them is a fundamental change to the Internet's
> existing framework for congestion control.
Since we're repeating ourselves, I'll again say that encapsulators are not 
forwarding nodes from the viewpoint of the network they tunnel over. They are 
traffic sources.

> Not that I'm opposed to such a change (it might make sense, I'd have to go
> away and think about it), but if we're going to make such an architectural
> change, i) we should do so explicitly, and ii) such a requirement should fall
> on _all_ packet forwarding nodes - including regular routers, since they could
> equally possibly be given non-congestion-compliant traffic to forward.
Lars

signature.asc
Description: Message signed with OpenPGP using GPGMail