Re: [multipathtcp] LISA - Linked Slow-Start for MPTCP => ICCRG

[Michael Welzl <[e-mail]>]

Hi Yoshi!

Thanks a lot for asking!  I don’t think it’s a naive question at all.

*** DISCLAIMER START ***

I’ll preface my answer with a disclaimer: we focus our evaluations on the non-shared bottleneck case because it’s the worst case - when paths DO share a bottleneck, uncoupled Slow Start in MPTCP breaks goal 2 laid out in RFC 6356 (“do no harm”), and that should be reason enough to fix it.
So, by looking at the impact on Flow Completion Time (FCT) in the non-shared bottleneck case, we’re really not very fair towards ourselves. If the impact on FCT isn’t too bad then that’s in fact already a super good result. I want folks to understand that   :-)

Also, just as a reminder for everyone, slides and a paper with many results and explanations are at: http://heim.ifi.uio.no/runabk/lisa/

*** DISCLAIMER END ***


With this out of the way, let me try to answer your question.

At a high (simplistic) level, your question is a bit similar to asking “why doesn’t Cubic’s HyStart hurt?” - like LISA, it makes slow start less aggressive, and that leads to benefits.

The similarities stop there  :-)    HyStart attenuates SS much, much more (actually LISA doesn’t "attenuate SS" but tries to turn SS+number_of_subflows*IW into SS on the wire, and it only operates once, very briefly, not from a certain point until the end of SS). HyStart tries to persistently get a benefit by attenuating SS at just the right time based on delay measurements, whereas LISA does it temporarily after a fixed number of round-trips. So, as a result, whether LISA yields a benefit in the non-shared bottleneck case is pretty much a matter of luck. But the bottom line is: making SS a little aggressive can, by itself, sometimes be a good thing. At least it doesn’t seem to be a very bad thing.

At a finer-grain level, things may get a bit clearer when we look at an example.

Consider 2 subflows, with IW 10 and equal RTTs (just to keep things simple). The first subflow has cwnd=10, then 20, then 40. In the round where it reaches 40, the second subflow is started with IW=10. If you look at the diagram on page 4 of the slides I showed yesterday (sorry, I didn’t have time to explain that diagram in my presentation), you can see it - look for the point where y=40 and x=approx. 0.3:  https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-update-on-lisa-a-linked-slow-start-algorithm-for-mptcp-draft-barik-mptcp-lisa-01-00.pdf

So what you get is, without LISA:
flow 1, on path 1: cwnd = 10, 20, 40, 80, 160…
flow 2, on path 2: cwnd = X, X, 10, 20, 40…

and with LISA:
flow 1, on path 1: cwnd = 10, 20, 30, 60, 120…
flow 2, on path 2: cwnd = X, X, 10, 20, 40…

(“X" meaning “not active yet”)

So, for better or worse, with LISA, the burst size is different when flow 1 (probably the first) exceeds the capacity limit. This influences the amount of overshoot (which otherwise depends on the queue size and the BDP).
How good or bad different amounts of overshoot play out, depends on… well…  the queue length; the back off factor (e.g. better with Cubic than Reno; generally of course best with ECN+ABE   ;-)   ); the presence of TLP; ...

So it’s just not persistently a bad thing to reduce this burst size - unless, of course, your flows have just the right length for them to terminate early enough so that the reduced aggression yields an extra round-trip. That’s also a narrow range, the flow size must be greater than 10+20+40 packets for LISA to even kick in, but not large enough to exceed the bandwidth limit because then we’re back with this more random outcome described above.

Does that help?  Clearly it’s not simple … the non-linear impact of this SS burst reduction on the overshoot and, with it, the cwnd size immediately after slow start can be seen on slide 8 of the slides from yesterday - same short URL again:
https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-update-on-lisa-a-linked-slow-start-algorithm-for-mptcp-draft-barik-mptcp-lisa-01-00.pdf <https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-update-on-lisa-a-linked-slow-start-algorithm-for-mptcp-draft-barik-mptcp-lisa-01-00.pdf>

E.g. in this case, LISA strictly only made things better in the range where the queue length was between approx 8 and 20: the cwnd at the end was a bit higher, and that coincides with less retransmissions.

I hope that helps?

Cheers,
Michael



> On Nov 16, 2016, at 12:11 AM, Yoshifumi Nishida <[e-mail]> wrote:
> 
> Hello,
> I've tried to ask a naive question at the meeting, but I missed the
> chance due to time restriction..
> 
> If the paths don't share a bottleneck, i am guessing it might be too
> conservative especially when the paths are not competed with other
> flows.
> I am wondering why this is slightly conservative and doesn't hurt.
> Some cases should be true, but I just thought some cases are not.
> --
> Yoshi
> 
> On Mon, Sep 26, 2016 at 12:40 AM, Michael Welzl <[e-mail]> wrote:
>> Dear all,
>> 
>> LISA is a simple algorithm that couples MPTCP subflows in slow-start, to reduce bursts that happen when multiple sub-flows start up with a delay and all send their IW, all in SS.
>> We found this effect to be generally bad (i.e., improved with LISA :-) ) when subflows do share a bottleneck, and we find that this slightly more conservative behavior also doesn't hurt (actually, sometimes it's a benefit) when they do *not* share a bottleneck. After all, slow-start is very aggressive anyway - is it really so important for the 2nd, 3rd... subflow of MPTCP to be  *that* aggressive?
>> 
>> We presented it to MPTCP at the last IETF, and in Yokohama.
>> There's a draft: https://tools.ietf.org/html/draft-barik-mptcp-lisa-01
>> and a page with slides, a published paper with results, and code:  http://heim.ifi.uio.no/runabk/lisa/
>> 
>> The way ahead, as agreed with the MPTCP chairs, is to either publish via MPTCP if their future charter will allow, or else publish this via ICCRG.
>> Either way, for now, discussion of this draft should happen in the ICCRG mailing list. We authors would greatly appreciate feedback - so far, we didn't get many comments!
>> 
>> Cheers,
>> Michael (with Runa & Simone)
>> 
>> _______________________________________________
>> multipathtcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multipathtcp