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@xxxxxxx] Sent: Tuesday, January 21, 2014 8:12 PM To: Ross Callon; Eggert, Lars Cc: mpls@xxxxxxxx; 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