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> 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> 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
https://www.ietf.org/mailman/listinfo/mpls