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

[Edward Crabbe <[e-mail]>]

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.  The originating application who's traffic is
being tunneled should be responsible for congestion control, or lack there
of.  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.)

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.


On Thu, Jan 23, 2014 at 1:15 PM, Joe Touch <[e-mail]> wrote:

>
>
> On 1/22/2014 9:55 AM, Eggert, Lars wrote:
>
>> 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.
>>>
>>
> FWIW, the whole point of using UDP is to leverage the Internet's ability
> to interpret the tunneled traffic as application data - to manage it
> according to port-based flow interpretation.
>
> There's a cost associated with that privilege - the cost of needing to
> react to congestion. That doesn't require 1-RTT, TCP-friendly dynamic
> congestion control; it does mean *reacting* to congestion in some way, over
> some timescale more than just ignoring things.
>
> This should be expected of any tunneling system that encapsulates
> non-reactive flows - regardless of technology.
>
> Joe
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>