If the upper layers (the thing that runs over the tunnel) involves applications
over TCP over IP, or if it is otherwise responding to congestion in the same
way that we expect anything running over IP to respond to congestion, then we
don't want the tunnel to also independently try to respond to congestion (two
independent cooks cooking the same meal does not necessarily lead to success).
If the upper layer does not respond to congestion, then perhaps it shouldn't be
running over the open Internet (with or without a tunnel), unless the *total*
bandwidth that could be used is inherently quite low. On the other hand, it
might want to run within a data center or internally to a service provider
network with appropriate provisioning.
Ross
-----Original Message-----
From: Joe Touch [mailto:touch(_at_)isi(_dot_)edu]
Sent: Tuesday, January 21, 2014 8:12 PM
To: Ross Callon; Eggert, Lars
Cc: mpls(_at_)ietf(_dot_)org; IETF discussion list
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
MPLS in UDP) to Proposed Standard
On 1/16/2014 2:32 PM, Ross Callon wrote:
These tunnels are stateless
yep. (But they don't have to be.)
The tunnels strictly speaking do not have to be stateless. However, if you
want routers to actually implement them, and you want to scale in both
forwarding speed and number of tunnels, then yes they do have to be stateless.
There's clearly a problem though:
- tunnels must be stateless to be efficiently implemented
- transport layer tunnels must have congestion control
Saying that the only way we can make tunnels cheap is to make them break
the Internet isn't a good solution.
Maybe it's time to expect something that's inherently costly to end up
being expensive?
Joe