ietf
[Top] [All Lists]

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

2014-01-24 09:02:08
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:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Edward Crabbe
Sent: Thursday, January 23, 2014 1:27 PM
To: Joe Touch
Cc: mpls(_at_)ietf(_dot_)org; 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 
<touch(_at_)isi(_dot_)edu<mailto:touch(_at_)isi(_dot_)edu>> wrote:


On 1/22/2014 9:55 AM, Eggert, Lars wrote:
Hi,

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

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
mpls(_at_)ietf(_dot_)org<mailto:mpls(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/mpls

<Prev in Thread] Current Thread [Next in Thread>