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

Michael Welzl <michawe@ifi.uio.no> Mon, 26 September 2016 07:40 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83A112B0A2; Mon, 26 Sep 2016 00:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZrGNUAmv_5g; Mon, 26 Sep 2016 00:40:56 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E19D12B09F; Mon, 26 Sep 2016 00:40:55 -0700 (PDT)
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1boQWz-0007Ky-K6; Mon, 26 Sep 2016 09:40:53 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1boQWz-0005i4-6X; Mon, 26 Sep 2016 09:40:53 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Sep 2016 09:40:51 +0200
Message-Id: <7A111AD3-3E4C-43D1-999A-F383428103AC@ifi.uio.no>
To: multipathtcp@ietf.org, iccrg@irtf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 7 sum msgs/h 2 total rcpts 46667 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.21, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: CA91EA3ECAC00D0B2052FA2F86BD40368B287EED
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 1 bait 0 mail/h: 2 total 11187 max/h 21 blacklist 0 greylist 0 ratelimit 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/zQrY-ZMy1qu-9yqV-09Zg3CWTK0>
Subject: [multipathtcp] LISA - Linked Slow-Start for MPTCP => ICCRG
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 07:40:59 -0000

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)