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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 15 November 2016 15:11 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 7805E129464 for <multipathtcp@ietfa.amsl.com>; Tue, 15 Nov 2016 07:11:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 fIUGGIy1D29x for <multipathtcp@ietfa.amsl.com>; Tue, 15 Nov 2016 07:11:13 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED941297CC for <multipathtcp@ietf.org>; Tue, 15 Nov 2016 07:11:09 -0800 (PST)
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 954CB2786EF for <multipathtcp@ietf.org>; Wed, 16 Nov 2016 00:11:07 +0900 (JST)
Received: by mail-vk0-f43.google.com with SMTP id p9so91000516vkd.3 for <multipathtcp@ietf.org>; Tue, 15 Nov 2016 07:11:07 -0800 (PST)
X-Gm-Message-State: ABUngvfZ0s3MampEbGbERbD4AkArI517wFuXFFxnC6b5CdX1CYWSQYpDJ6n3cyKGshfctNXgYc5dCIbdi1Cpsw==
X-Received: by 10.31.5.132 with SMTP id 126mr11917756vkf.164.1479222666060; Tue, 15 Nov 2016 07:11:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.84.152 with HTTP; Tue, 15 Nov 2016 07:11:05 -0800 (PST)
In-Reply-To: <7A111AD3-3E4C-43D1-999A-F383428103AC@ifi.uio.no>
References: <7A111AD3-3E4C-43D1-999A-F383428103AC@ifi.uio.no>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Tue, 15 Nov 2016 07:11:05 -0800
X-Gmail-Original-Message-ID: <CAO249yfA_h3tksS_K204ZTuYx1NiUXjf2HD47Jb2y6VWcn4NSA@mail.gmail.com>
Message-ID: <CAO249yfA_h3tksS_K204ZTuYx1NiUXjf2HD47Jb2y6VWcn4NSA@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/EaobRp2WV5_S3SbYODrbD2Rj9Rw>
Cc: multipathtcp <multipathtcp@ietf.org>, iccrg@irtf.org
Subject: Re: [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: Tue, 15 Nov 2016 15:11:26 -0000

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 <michawe@ifi.uio.no> 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
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp