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

["Henderickx, Wim (Nokia - BE)" <[e-mail]>]

I believe that we are overlooking one major thing in this discussion. The plain MPTCP solution proposes a full proxy at different points, meaning it reinitiates a TCP/MP-TCP session at various points to accommodate the various TCP timers, etc
The draft requires each proxy to compensate for various delays in various segments. This has is deployed in various networks, mainly mobile to improve QoE today w/o MP-TCP. The plain MP-TCP enhances this solution and allows flows which are bigger than a given path to still work, whereas today they break.
Example here

EndHost (TCP) <——> (TCP) CPE (MP-TCP proxy) <——>  (MP-TCP proxy) Concentrator) (TCP) <——> App

As such the CPE and concentrator have to compensate for the various delays/feedbacks in the protocol stack.




On 04/06/16 02:46, "multipathtcp on behalf of David Allan I" <[e-mail] on behalf of [e-mail]> 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).
>
>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.
>
>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.
>
>
>>
>> <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.
>DA4> I gathered that!
>
>
>>
>> <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).
>
>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 then need to be deployed, and yes - that's work.
>>
>> DA3> Agreed
>>
>> Have a good weekend
>
>+1 and cheers...
>
>DA4> cheers as well
>Dave
>
>_______________________________________________
>multipathtcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/multipathtcp