Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

[Joe Touch <[e-mail]>]

On 6/3/2016 4:40 PM, David Allan I wrote:
> Hi 
>
> <snipped>
>> They might use a different sort of congestion feedback, one that isn't "TCP-compatible". That's actually desirable here - i.e., having congestion reaction happen over different timescales than TCP.
>>
>> DA2> As the tunnel leg would have a different RTT, would that not be true by definition?
> The difference needs to be on significantly different timescales. Sure, a deployment might work if the tunnel is 1/10 or 1/100 the E2E RTT, but you can't know that for the tunneled traffic. It's safer to run congestion feedback on the tunnel at 10x (or some value bigger than) the largest RTT that can ever occur.
>
> DA3> I think we are talking past each other here. I'm not sure quite what you're arguing other than it is not TCP with the rationale being timescales.  IMO the largest RTT that can occur is irrelevant (and I believe you are discussing E2E). And the ratio of E2E to tunnel is also a don't care as near as I can tell.  My best guess is you think TCP RTT measurement timescales for the tunnel itself is inadequate. Is that correct?

I think that if the routing algorithm uses TCP timescales to shift and
the E2E traffic uses TCP timescales to backoff, the two will interact in
bad ways.

When I say "RTT" for the tunnel congestion, I should have been more
clear - I'm talking about the timescales on which the traffic load
balancing picks different paths. That's not RTT, but it's a similar kind
of cycle time.

...

>>> - by recovering from loss, it increases latency and jitter
>>> DA> AFAIK, any loss does that irrespective of the delivery mechanism. In the hybrid access case you are correcting loss with a smaller RTT are you not?
>> You don't need to correct losses for an IP tunnel. You want to reduce their probability, but you definitely don't want to stop the stream and recover. IP is allowed to lose packets. The loss recovery should happen E2E.
>>
>> DA2> unfortunately that sounds like dogma to me. You already have the underlying radio layers correcting loss for the on-air interface portion.
> Some radios do, some do not. Packets are lost in a lot of different places, including routers.
>
> The fact that IP is "best effort" isn't dogma; it's the one of its defining properties.
> DA3> Therefore in your world a link or path that provides a reliable transport service is not allowed.  I would say at best you could argue that it is redundant. I'd simply describe it as an artifact of other technical choices.

My view is that tunnel ARQ is an expensive choice and applicable in only
a very specialized set of environments. I don't see that sort of
specific environment being the intended use case for this approach.

...
>> DA2> No IP does not require ordered delivery from the network. But if it was a way of life rather than a rare event it would be a problem. Poorly done striping of traffic across heterogeneous links with very dynamic transfer characteristics would result in a lot of "out of order" receipt to correct. 
> First, anything that uses IP and treats misordering as an error is itself broken. IP is best effort and doesn't guarantee in-order delivery. However, as noted, there are mechanisms to reduce the reordering at the egress collection point, esp. for striped paths.
> DA3> It may not treat it as an error, but it does treat it as far more than a minor inconvenience.  Ask the vendor whose initial OC-192 interfaces did not provide ordered transmission. (dumb striping across concatenated OC48s)

OC192 provides SONET service, where reordering is not permitted (at
least not outside the jitter specified for a connection).

IP is a different service with different expectations.


>
> <snipped>
>
>> No, it's design-constrained. MPTCP isn't designed for plug-replaceable load detection or traffic distribution. Dynamic multipath routing is already designed for that.
>>
>> DA2> You are looking for an a la carte menu of functions?
> Not necessarily; I'm saying that MPTCP comes bundled with one solution that fits its use for two TCP endpoints. That need not be the best solution when used as a tunnel. And - more to the point - we already have a wide variety of those solutions.
>
> DA3> Ahh, then if I understand you, you are objecting to the need for functionality at both ends of the tunnel vs. just decap at one end.

There's functionality at both ends of the tunnel in both approaches.

I'm objecting to the use of TCP (any form of TCP) to tunnel IP traffic.


>
> <snipped>
>> DA2> So for mechanisms that age out assignment of load spreading buckets, that is great for the core. But at the edge with very few flows, and the arrival rate I approaching link rate it strikes me that there is only a fairly narrow range of operation in which I could successfully stripe across all uplinks safely. Is that your take as well?
> The way in which the routing protocols are tuned for core vs edge operation may certainly vary. The routing protocol solution gives you exactly the flexibility to make that decision and adjust as needed.
>
> DA3> I'm not sure why you keep calling it a routing protocol solution when it is simply forwarding and some ongoing supervision to tell you when striping is not a good idea. 
>
> DA2> Now your original assertion was that for MPTCP, something needed to be invented, whereas for dynamic multipath nothing new was required.  From what I have gleaned from this conversation is that both require specification to produce a workable solution.
>
>  MPTCP needs a spec to indicate how to tunnel. The existing solution uses existing tunnel mechanisms and existing routing protocols, but needs no new spec.
>
> DA3> It sounds like it also needs "experience" to know how to tune it. 

First, we already have a lot of that experience (this isn't anywhere
near a new issue).

Second, at least you can tune the dynamic routing variant. MPTCP doesn't
have that option unless you rewrite that spec too.

> Both then need to be deployed, and yes - that's work.
>
> DA3> Agreed
>
> Have a good weekend

+1 and cheers...

Joe