Hi Spencer,

see below

> Am 01.02.2018 um 21:21 schrieb Michael Richardson <mcr+i...@sandelman.ca>:
> Spencer Dawkins at IETF <spencerdawkins.i...@gmail.com> wrote:
>> This is Mirja's Discuss thread, and MPTCP is her working group, and
>> she knows MPTCP better than I do, but I'm confused about one thing, as
>> I'm reading this discussion ...
> ...
>> If I'm understanding the discussion, the desire is to use MPTCP to
>> handle failover to another pre-established flow quickly, and Mirja's
>> point is that normal MPTCP would just use both flows

No. That was not my point at all. You can use both flow simultaneously with 
MPTCP pr configure it to automatically failover but making one or some of the 
subflow backup subflows. These are other valid use cases. However for 
transmission where you want neither of these two options (but fails when one 
specific connection fails), you should not use MPTCP but a single TCP 

>> - so, not
>> actually failing over, but if you provision for each flow to carry all
>> your traffic, which you would have to do in order to handle failover
>> anyway, I'm not sure why it's bad to let MPTCP do what it would do
>> normally, and load-share across overprovisioned paths.
> I also don't know why it would be bad.
> My other question is, what happens in MPTCP is one path is significantly
> faster (or less lossy) than the other path?  Won't the window open up
> significantly on that path and simply attrack more traffic?

If you use coupled connection control to would sent more data over the faster 
path. But I don’t this was the use case here rather than automatic failover 
(with can be done with MPTCP as explained above).


> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-

Anima mailing list

Reply via email to