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

[Joe Touch <[e-mail]>]

On 6/3/2016 5:46 PM, David Allan I wrote:
> And when I thought I was done for the weekend :-) I've enjoyed the discussion, so just one more :-) 
>
>> <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.
>
> DA4> I can understand that for dissimilar algorithms (like TCP over ATM-ABR).

Actually, similar algorithms layered over each other have already been
shown to interact in bad ways - for TCP in particular.

> 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.
>
> DA4> In the context of the solution you've been discussing, there is measurement time, and the arrival rate which can be striped when compared to the delta of individual path latencies. I would have to believe you need to measure that frequently in the context that an ordering guarantee is a single ended function with no redress.

There's the measurement time, the time to make a decision, and the
hysteresis needed to avoid route flapping. And you can tune each of
those independently when you use dynamic routing, but it's not as easily
changed for MPTCP.

> DA4> That is where I would lean to a double ended function, I can actually offer the guarantee , and can stripe traffic across a greater disparity in path throughput vs. shutting striping down past a certain threshold in disparity. Which when considering how asymmetric DSL is, becomes a rather large benefit IMO.
>
> ...
>
>>>> - 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.
> DA4> Well for your approach, yes. As per my summary above
>
> ...
>>> 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 
>> DA3> than a minor inconvenience.  Ask the vendor whose initial OC-192 
>> DA3> interfaces did not provide ordered transmission. (dumb striping 
>> DA3> 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.
>
> DA4> You missed my point, there was a router that misordered packets and caused much unhappiness. All the deployed blades needed to be replaced IIRC. Yes end systems will tolerate it, but not as a way of life.

A system that runs IP but does not tolerate reordering as a "way of
life" isn't IP. If there's a cost at any level, it needs to be adapted
at the endpoint (install some playout buffers and do local reordering).
Expecting in-order delivery should never be a requirement of IP.

However, as noted, there are ways to reduce the amount of persistent
reordering in multipath routing already. I cited one of them; there are
others.

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

Sorry I overlooked this one - I call it a routing protocol solution
because the routing protocol is the distributed algorithm that detects
path properties and decides how to configure forwarding accordingly.
That's what routing is. Forwarding is what the router does with incoming
packets based on the configuration of its forwarding table based on the
routing protocol. (A routing table is the data used by the routing
protocol to coordinate the algorithm and derive the forwarding table).

>>  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).
>
> DA4> SO I understand :-)
>
> Second, at least you can tune the dynamic routing variant. MPTCP doesn't have that option unless you rewrite that spec too.
>
> DA4> Any HA solution will have policy as the economics of using each interface are different. So both solutions will have overall very similar options when the dust settles.

Both systems can be extended to have identical capabilities - except for
the part about segment boundaries and requiring ARQ stalls to fill in
dropped packets that MPTCP incurs - but dynamic routing solutions
already have all of these features now. Extending MPTCP to provide those
capabilities is just reinventing the wheel.

Joe