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

[John E Drake <[e-mail]>]

Ed,

I completely agree with your email, below.  As an aside, the L2 packets that Lars is worried about are transported over a pseudo-wire using MPLS, so the logical place to place congestion awareness is in the pseudo-wire endpoints.  I remember that this was in the PWE3's charter some time ago.

Yours Irrespectively,

John

From: mpls [mailto:[e-mail]] On Behalf Of Edward Crabbe
Sent: Thursday, January 23, 2014 1:27 PM
To: Joe Touch
Cc: [e-mail]; Eggert, Lars; Noel Chiappa; IETF discussion list
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls