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