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

[Joe Touch <[e-mail]>]

On 6/3/2016 3:03 PM, David Allan I wrote:
> Hello again:
>
> Replies in line "DA2>" and some snips to eliminate clutter....
>
> <snipped>
>> Perhaps, but MPTCP is the wrong solution for an IP tunnel for many reasons:
>>
>> - it will layer congestion control on top of congestion control for 
>> all transports in the payload IP that already support it (which they 
>> should)
>> DA> Would that not be true of any tunnel mechanism that used feedback of the tunnel leg as well as the e2e application?
> 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.

>> - it fails to preserve payload IP messages inside a single TCP 
>> segment, which increases loss due to a lack of fate-sharing and 
>> increases latency and jitter
>> DA> I apologize for not getting your point here.
> When you write a buffer to TCP, TCP has no obligation to preserve that as sitting inside a single TCP segment. TCP does not preserve these message boundaries.
>
> If your message spans multiple TCP segments, then you depend on BOTH of them arriving. The probability of losing one or more of two segments is higher than the probability of losing only one segment. That's the fate-sharing part - you end up taking a RTT to recover (just like if you lost the IP packet) when either TCP segment fails to arrive. That loss recovery increases delay and jitter.
>
> DA2> Understood, but true of any fragmentation mechanism. 

We're not talking about fragmentation. Even if TCP runs over IPv6 and
has 1200+B segments, there's absolutely no guarantee that a sequence of
576B IPv4 packets will each occur solely inside one TCP segment. TCP can
- and will - pack, straddle, or do anything else it wants with the
buffers it is given.
>> - 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.

> If you have high random loss on a path you might employ FEC, which would increase delay but in a fixed way.
>
> DA2> It takes a little FEC to fix a bit error, it takes a lot to reconstruct a missing packet. The mode of failure for a path is packet loss. So I do not really see FEC as a starter.
Some paths do employ FEC using block codes that are tolerant to burst
losses - which is what packet loss along the tunnel would look like. But
sure, it's up to you whether you need that level of recovery or not.

> If you really do want ARQ loss recovery on a sub-path, then you can decide whether to implement that or not. However, you don't want to force that recovery all the time nor do you want to couple it with strict reordering - which IP does not require.
>
> 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.


>> - it can use only one load monitoring mechanism (the one built-in)
>> DA> How many did you want?
> Maybe you want a variant that isn't already inside MPTCP. The point is that the load monitoring mechanism isn't configurable or easily replaced.
>
> DA2> Load monitoring or load spreading.  I do not understand why you would want a configurable monitoring function.?

There are a lot of ways of measuring load and a lot of ways of
interpreting those measurements. The variant in MPTCP represents one
point in that space. It might not be the one you want - you might want
to detect congestion in groups of tunnels as sets rather than as
individual paths, e.g.
>> - it can use only one traffic distribution mechanism (the one 
>> built-in)
>> DA> If you are saying it is "implementation constrained", well go 
>> DA> figure :-)
> 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.

>> That's a lot of baggage vs. just using tunnels and existing dynamic multipath routing -- and the latter doesn't require a new spec.
>>
>> DA> Can you point me to the feedback mechanisms embodied in making dynamic multipath work? 
> http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5212-46.html
>
>> And if you are striping flows across multiple paths (absolute requirement in my application), any indication of how successful this is in minimizing the residence time of packets in the reordering function?
> http://www.sigcomm.org/node/2597
>
> DA2> OK, I see where you are going..... 
> <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.

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

Both then need to be deployed, and yes - that's work.

Joe