Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Joe Touch <[e-mail]>]

On 1/21/2014 6:40 PM, Ross Callon wrote:
> 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).

That's true, but is an issue only if the tunnel congestion control is 
dynamic over the same or shorter timescales than the 
congestion-controlled traffic being tunneled.

> 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.

Sure, but who would enforce that? If you're using MPLS, the only entity 
in a position to know (whether the traffic is congestion controlled or 
not) is the tunnel encapsulator.

> On the other hand, it might want to run within a data center or
> internally to a service provider network with appropriate provisioning.

All bets are always off for private networks; they need not comply with 
any Internet standards or expectations, even when they leverage Internet 
header formats and protocols.

But that's not a strict constraint of the proposed approach here.

Joe


> Ross
>
> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Tuesday, January 21, 2014 8:12 PM
> To: Ross Callon; Eggert, Lars
> Cc: [e-mail]; 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
>
>
>