Re: [multipathtcp] MPTCP Schedulers

Zhen Cao <zhencao.ietf@gmail.com> Sat, 23 March 2019 20:39 UTC

Return-Path: <zhencao.ietf@gmail.com>
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 86888130D7A for <multipathtcp@ietfa.amsl.com>; Sat, 23 Mar 2019 13:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hFTvPqg4XmB0 for <multipathtcp@ietfa.amsl.com>; Sat, 23 Mar 2019 13:39:08 -0700 (PDT)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4231200B3 for <multipathtcp@ietf.org>; Sat, 23 Mar 2019 13:39:08 -0700 (PDT)
Received: by mail-ot1-x32c.google.com with SMTP id x8so4839164otg.7 for <multipathtcp@ietf.org>; Sat, 23 Mar 2019 13:39:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XGwPdBpmCk92jJR2wIIXxV8My11i+k9Z9/YXCiASpkc=; b=ZeLXBbzUJYoGyLioiFUT1UYSkyiXJjtJjhG5At/M7MQY3QgjXYMaepFUWKK4iDNYmP jUfjFVn4m4vEYUgsBAZgAFlAbiUB+bYImfJ6PVGfKMuw6aja2GS6u9OUts2cL3ZO4uNc ox1GRow+TXTdTYUZlX4G/LTvb8n6aw19PT2nf6H4rHYCUKXYfb3BPUwjbGE9Gqv7BcJA LfuM2LAF7yTaUm4qLDGDfewmWYWtbkGRoAwWRS2R5TD9qoLJrl82WdVPKP+kPVolCI8U PwSsWJIKampFse0SZcG42OjpZU4zCHlnBJkwU+2ZDwzrWxC4w68E2B29kHalO9J2qSvj ohJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XGwPdBpmCk92jJR2wIIXxV8My11i+k9Z9/YXCiASpkc=; b=oCG+3aYO6ODRmLXolZD4letonH1pe2h81MwkNbm3kLfE3oCQrNneYqFnvN6zyQFaLq p47aSrkPjFiANMtPwLJ1eORajPdYH3VYf1LsZDkWmrzgGToRzf1WCfZQQpSEz2Qt8w+5 S1E646f3XLYu9V4ZEgBKivQBd0x6fNdBK8okbseDWo2uuKGkMDRxQhnEUeECorYqijCh PtyT9Owv3un1Fx6/KfwibuVodOr67lDQUeUudF2eUg+VOaAskbNDeN5sivz0shA1qlh5 JcY5QvpDvhCTndiygnqKY2b1ymBdsU+7VeTilUD1ijeVV2eQdqtaAohm+3oyfNzuyazB CwmA==
X-Gm-Message-State: APjAAAVdethtfovfZRpYKWfLiUt55LXS4aIobtrHnS9RJM2do5UHAxjN OUtUnCgccDrxFt8uNfELhSyPAw1cLX0PEDojwpU=
X-Google-Smtp-Source: APXvYqwaBam0zigjDGOaJk7jBbyOlhm1sp5iFxzdCbl4/qb0zzDcm8FBdlnHEW5PMoV8CTw6vEdoShxSN5KkK+UiUTM=
X-Received: by 2002:a9d:5501:: with SMTP id l1mr11958613oth.143.1553373547462; Sat, 23 Mar 2019 13:39:07 -0700 (PDT)
MIME-Version: 1.0
References: <a939bc37-16ed-9d8a-15d7-16dfec630290@cs.pub.ro> <20190215180722.GR1880@MacBook-Pro-19.local> <41d2eef4-67e8-62a5-5d05-b6248d2293e5@uclouvain.be> <1MKd92-1gcaMb0Y7I-00Kxa3@mrelayeu.kundenserver.de> <LO2P123MB17926F324140C813F236CA48EB630@LO2P123MB1792.GBRP123.PROD.OUTLOOK.COM> <44765cb5-d0ed-2f44-a41b-25931f69d1a1@uclouvain.be>
In-Reply-To: <44765cb5-d0ed-2f44-a41b-25931f69d1a1@uclouvain.be>
From: Zhen Cao <zhencao.ietf@gmail.com>
Date: Sun, 24 Mar 2019 04:38:58 +0800
Message-ID: <CAFxP68w1CLnEetzMJ_D6erEs8+hRHZX4C66=USnS82RTngqhzQ@mail.gmail.com>
To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>
Cc: "philip.eardley@bt.com" <philip.eardley@bt.com>, "alexander@froemmgen.de" <alexander@froemmgen.de>, "cpaasch=40apple.com@dmarc.ietf.org" <cpaasch=40apple.com@dmarc.ietf.org>, "vladimir.olteanu@cs.pub.ro" <vladimir.olteanu@cs.pub.ro>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/aKLiCDqd5dwVcBn3C1jwSwSrCqA>
Subject: Re: [multipathtcp] MPTCP Schedulers
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 23 Mar 2019 20:39:10 -0000

Hi Olivier,

> Yes. In the hybrid access networks use case, the schedulers are
> optimised to first use the DSL network and then overlfow over the LTE
> network when the DSL is full.

We also have a similar case where the server would like to saturate
WLAN and then overflow to LTE, where another scheduler will be needed.

But  we at least have two design choices here:
1) first one, as you said, the fine-grained remote control of the
schedulers used on the peer.
2) extension of the spare space before the Backup bit in
MP_JOIN/MP_PRIO.  That's, keep the current Backup bit as it is( use
the backup flow only in the event failure).  And in the meantime use
the spare bits as the ‘Saturate and Overflow(S&O)’ priority bit; The
server who receives sub flows marked with S&O, will first saturate the
prioritized subflow and then overflow to the others.

I am in favor of the second one if the cost based prioritizing is only
case we want to solve, and the priority can be expressed as binary.
This does not need new options space for MPTCP anyway.

-Zhen