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

[Joe Touch <[e-mail]>]

On 1/23/2014 6:31 PM, Joel M. Halpern wrote:
> Joe, while your argument is internally consistent, it is not consistent
> with history.

That's also why we're not exchanging email over X.25. We learn and move on.

However, the fact that tunnel heads ought to act like hosts is an issue 
I've been raising in the IETF for over 15 years, and was the primary 
reason why I argued for transport mode support in routers for tunneling 
(see RFC 3884).

> We have not demanded that tunnel entries behave fully
> like source hosts for any of the other myriad kinds of tunnels we have
> done over the years.

That has been a continual mistake, one that a group was formed in 2005 
to address, which resulted in an INTAREA document on this:

http://tools.ietf.org/html/draft-touch-intarea-tunnels-01

That doc has been fallow for a while largely because the problem and its 
complexity hasn't been fully appreciated. We're hoping to correct that 
and revive it, FWIW.

> If we take your logic as stated, then the usage of IPSec over UDP would
> be required to apply congestion control unless it knew that all the
> content traffic was TCP.  Is that really your intent?

Yes, and that's already what RFC 5405 says. The fact that IPsec-UDP 
encap doesn't address this is because RFC 3948 predates RFC 5405.

This document (mpls-in-udp) does not, however.

Joe

> Yours,
> Joel
>
> On 1/23/14 4:38 PM, Joe Touch wrote:
>>
>>
>> On 1/23/2014 1:27 PM, Edward Crabbe wrote:
>>> Part of the point of using UDP is to make use of lowest common
>>> denominator forwarding hardware in introducing entropy to protocols that
>>> lack it ( this is particularly true of the GRE in UDP use case also
>>> under discussion elsewhere).
>>>
>>> The tunnel is not the source of the traffic.  The _source of the
>>> traffic_ is the source of the traffic.
>>
>> To the Internet, the tunnel encapusulator is the source of traffic.
>> Tracing the data back further than that is a mirage at best - and
>> irrelevant.
>>
>> The tunnel head-end is responsible for the tunnel walking, talking, and
>> quaking like a duck (host). When the tunnel head-end knows something
>> about the ultimate origin of the traffic - whether real, imagined, or
>> from Asgard - then it has done it's duty (e.g., that it's already
>> congestion controlled).
>>
>> But that head end is responsible, regardless of what it knows or
>> doesn't. And when it doesn't know, the only way to be responsible is to
>> put in its own reactivity.
>>
>>> The originating application
>>> who's traffic is being tunneled should be responsible for congestion
>>> control, or lack there of.
>>
>> Perhaps it should be, but that's an agreement between whomever
>> implements/deploys the tunnel headend and whomever provides the
>> originating traffic to them. The problem is that this isn't true for the
>> typical use case for this kind of encapsulation.
>>
>> I.e., if we were talking about MPLS traffic that already was reactive,
>> we wouldn't be claiming the need for additional encapsulator mechanism.
>> It's precisely because nothing is known about the MPLS traffic that the
>> encapsulator needs to act.
>>
>>  > Are we advocating a return to intermediate
>>> congestion control (I like X.25 as much as the next guy, but...).  This
>>> is a very stark change of direction.
>>>
>>> I think mandating congestion control  is not technically sound from
>>> either a theoretical (violation of end to end principle, stacking of
>>> congestion control algorithms leading to complex and potentially
>>> suboptimal results) or economic perspective (as a very large backbone,
>>> we've been doing just fine without intermediate congestion management
>>> thank you very much, and I have 0 desire to pay for a cost prohibitive,
>>> unnecessary feature in silicon.)
>>
>> Write that up, and we'll see how it turns out in the IETF. However,
>> right now, the IETF BCPs do require reactive congestion management of
>> transport streams.
>>
>> If you don't want/like that, then either don't use transport
>> encapsulation, or change the BCPs.
>>
>>> I get Lars comments regarding reach, to some limited extent.
>>>   Ultimately, the implication seems to be that the protocols riding the
>>> L2 network will have no form of congestion control and are fundamentally
>>> different than protocols that would reside on a typical wan.  I have
>>> some serious doubts about this, although I'm sure this is the case in
>>> some specialized environments.  At any rate, it seems to me that a stern
>>> warning regarding edge filtering on interdomain boundaries will be
>>> sufficient.
>>
>> My concern may be slightly different that his. My concern is that you
>> want the benefits of a UDP header, but don't like the responsibilities
>> that come along with it.
>>
>> Joe
>>
>>