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

[David Allan I <[e-mail]>]

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?

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

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

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.

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. 

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

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

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

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.

Dave