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