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

[Joe Touch <[e-mail]>]

On 6/3/2016 12:29 PM, David Allan I wrote:
> Hi Joe:
>
> Comments below prefaced by DA>
>
> ...
> 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.

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


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

If you have high random loss on a path you might employ FEC, which would
increase delay but in a fixed way.

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.

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

> - it can use only one traffic distribution mechanism (the one built-in)
> DA> If you are saying it is "implementation constrained", well go 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.

> 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

> DA> If all we are talking about is a slightly smarter ECMP , IMO it does not cut it.

So you want something dumber than ECMP?

Joe