Return-Path: 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 D1F531294E4 for ; Sun, 13 Nov 2016 22:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 j87M13xPijjU for ; Sun, 13 Nov 2016 22:14:21 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 ED8BA1294DC for ; Sun, 13 Nov 2016 22:14:20 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id 189so27602778pfz.3 for ; Sun, 13 Nov 2016 22:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=RO2lpgUUbotTFOSwnJdnqMW33BD91UZ+4p3V13qbLPs=; b=r2xOrnDQpISkfdlkNTH/qoKIxGDSGU/c94mJWGPY4bYByjgfh3jXIFwE3C6EypRKh+ KwccSOaMcjVqAc8/COttcb5sw59FF8rIR/Hg3tZ6F2PE2Nk4e6jnOmkwJ++hGBOsFIUF nbt7T03PtOrfKRY3HihGae9GCD8E/gc3d/VoEM8F2oshUWg6c2qTANS0GyqM9kiTOBGw Zs4aSIF8JhAUfjvmW6PEq2SaPGBI/O/x7fN5XZz2ZuQHrtVNkdKZaMChYCwBISKIFw3Y zWU7x0MCx8/V5dP0JSq+MEYTVD4gTTi+5QL3Da5grEIsMB87UhMRo4mxkOCSidAdJEKt ULxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RO2lpgUUbotTFOSwnJdnqMW33BD91UZ+4p3V13qbLPs=; b=dNVKw9hTMxmPIsGoCxb6bTGsO2lxDq6n+n+kpZiiZI8QKeCd63fugLskEPokTAqNCr i+N9vZ9Q289kwUJvLHCobBFs45hRPmElAv5TV9/MUAg7Ya/d2oX/I90EcTarl5JUmXaM /20jXaD9p7FXfmpYW5habCyLZ7Z9fndcvutbudJWUyqZX9NxBr5s+22BlLtocp8jFB4+ T4RJRTqFTL+eGWRDAqRjDHEZxLDifMMKyTw87NMYGnUhQPhO6NLekIYMyfdMl4y0vd3f cp6WFqWUXsLOb6PhzSEMH5uffvCQ0o9+3vazUG6iXJPT3x2YnG5nvHlcWpGeX03wyMpi n6Tg== X-Gm-Message-State: ABUngvcxQ2ROvxg5pmnmbF7U5/QUrapZsTCvKIiYCAPTF4QUhzkDSVZWhBl2vHiQxEb97Q== X-Received: by 10.98.87.199 with SMTP id i68mr33585028pfj.18.1479104060536; Sun, 13 Nov 2016 22:14:20 -0800 (PST) Received: from dhcp-8fca.meeting.ietf.org (dhcp-8fca.meeting.ietf.org. [31.133.143.202]) by smtp.gmail.com with ESMTPSA id vz6sm32088573pab.15.2016.11.13.22.14.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 22:14:19 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_ED6C2EA0-73C8-493B-95A0-AF18B898D619" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <826bf9ab-e9b7-a89b-28de-676deece8a4b@uclouvain.be> Date: Mon, 14 Nov 2016 06:14:17 +0000 Message-Id: References: <581F2334.8010403@uclouvain.be> <20161113075145.GH4269@Chimay.local> <826bf9ab-e9b7-a89b-28de-676deece8a4b@uclouvain.be> To: =?utf-8?Q?Fabien_Duch=C3=AAne?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Multipath TCP Address advertisement 4/5 - Priorities X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 06:14:23 -0000 --Apple-Mail=_ED6C2EA0-73C8-493B-95A0-AF18B898D619 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, After discussion at IETF97, I think it=E2=80=99s clear that this = proposal - the idea of =E2=80=9Cpriority=E2=80=9D - means different = things to different people. For example: a) A percentage split - but would that only kick in when one link is = full? Or would all traffic always be split? b) Prioritising subflows, overflowing only when one is full c) QoS (latency, bandwidth, etc) values d) etc etc Personally I think only (b) makes sense at the subflow level, everything = else is far too complex to signal in a few bits. Whether it is of use to = people in the real world, however, I don=E2=80=99t know, however! I also think it=E2=80=99s entirely feasible to achieve a lot of the = traffic engineering here by using TCP control signals - ACKs and window = size - to slow down communications. As a sender you can already control = rate based on your local policy, and at the receiving end you could use = ACKs, ECN, window, etc. This proposal needs a much clearer idea of what it=E2=80=99s trying to = achieve before we could consider it for merging. Regards, Alan > On 14 Nov 2016, at 01:58, Fabien Duch=C3=AAne = wrote: >=20 > Hello, >=20 > Inline, >=20 > On 11/13/2016 08:51 AM, Christoph Paasch wrote: >> Hello, >> while I support adding more info to MPTCP to allow a finer-grained = control >> of the peer's scheduling, I think the priority-bits should be defined = in a >> more precise way. >>=20 >> I see the this work here as a way to allow for a more deterministic = behavior >> when an MPTCP-client connects to a MPTCP-server. As of today, when I = on my >> mobile device connect to a server that is outside of my control, the = only >> way I can tell the server to schedule traffic in a certain way is by = using >> the backup-bit. Upon which I can expect the server to not send = traffic on >> this subflow unless the primary subflow is broken. >> This kind of "configuration" is not sufficient for most use-cases. >> I see the priorities as a way for the client to tell the server = exactly >> what kind of scheduling it expects to meet a certain = "QoS-requirement". >> So, we should clearly specify what each priority means. > The way I wrote the draft was more like "ok, let's tell the server = that, if possible, > I'd like to receive most on the trafic on this subflow, then this one, = then this one". > This is why I wrote >=20 > "The priority field MUST be interpreted as an unsigned integer value = with the highest > numerical value being the most preferred one." >=20 > While I agree that we should be as specific as possible, I wonder how = we could be more > explicit about this. Any idea? > If we are too specific, like saying "always schedule on the highest = priority subflow, > until the windows is full, then skip to the next one" we are actually = writing a strict priority > scheduler, and I was hoping that we could leave the priority open to = more creative ways > of handling the priorities. > It's a MAY because I'm not sure that making the respect of the = priority a MUST would > be interesting, for backward compatibility, but also because the = priorities of one host > could clash with the other's own interest. >=20 >> If we leave the interpretation of the priority-bits open to the >> implementation, hosts still cannot rely on getting a certain service = by >> the peer when set the priority bits. >>=20 >>=20 >> Thoughts? >>=20 >>=20 >>=20 >> Cheers, >> Christoph >>=20 > Cheers! >=20 > Fabien >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp = --Apple-Mail=_ED6C2EA0-73C8-493B-95A0-AF18B898D619 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

After discussion at IETF97, I think it=E2=80=99s clear that = this proposal - the idea of =E2=80=9Cpriority=E2=80=9D - means different = things to different people. For example:

a) A percentage split - but would that = only kick in when one link is full? Or would all traffic always be = split?
b) Prioritising subflows, overflowing only = when one is full
c) QoS (latency, bandwidth, etc) = values
d) etc etc

Personally I think only (b) makes sense = at the subflow level, everything else is far too complex to signal in a = few bits. Whether it is of use to people in the real world, however, I = don=E2=80=99t know, however!

I also think it=E2=80=99s entirely = feasible to achieve a lot of the traffic engineering here by using TCP = control signals - ACKs and window size - to slow down communications. As = a sender you can already control rate based on your local policy, and at = the receiving end you could use ACKs, ECN, window, etc.

This proposal needs a = much clearer idea of what it=E2=80=99s trying to achieve before we could = consider it for merging.

Regards,
Alan

On = 14 Nov 2016, at 01:58, Fabien Duch=C3=AAne <fabien.duchene@uclouvain.be> wrote:

Hello,

Inline,

On 11/13/2016 08:51 AM, Christoph Paasch = wrote:
Hello,
while I support adding more info to MPTCP to allow a = finer-grained control
of the peer's scheduling, I think = the priority-bits should be defined in a
more precise = way.

I see the this work here as a way to = allow for a more deterministic behavior
when an = MPTCP-client connects to a MPTCP-server. As of today, when I on my
mobile device connect to a server that is outside of my = control, the only
way I can tell the server to schedule = traffic in a certain way is by using
the backup-bit. Upon = which I can expect the server to not send traffic on
this = subflow unless the primary subflow is broken.
This kind of = "configuration" is not sufficient for most use-cases.
I = see the priorities as a way for the client to tell the server exactly
what kind of scheduling it expects to meet a certain = "QoS-requirement".
So, we should clearly specify what each = priority means.
The way I wrote the = draft was more like "ok, let's tell the server that, if = possible,
I'd like to receive most on the trafic on this = subflow, then this one, then this one".
This is why I wrote

"The priority field MUST be interpreted = as an unsigned integer value with the highest
numerical value = being the most preferred one."

While I agree that we should be as specific as = possible, I wonder how we could be more
explicit about this. Any idea?
If we are too = specific, like saying "always schedule on the highest priority = subflow,
until the windows is full, then skip to the next = one" we are actually writing a strict priority
scheduler, and I = was hoping that we could leave the priority open to more creative = ways
of handling the priorities.
It's a MAY because = I'm not sure that making the respect of the priority a MUST = would
be interesting, for backward compatibility, but = also because the priorities of one host
could clash with the other's own = interest.

If we leave the = interpretation of the priority-bits open to the
implementation, hosts still cannot rely on getting a certain = service by
the peer when set the priority bits.


Thoughts?



Cheers,
Christoph

Cheers!

Fabien

_______________________________________________
multipathtcp = mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

= --Apple-Mail=_ED6C2EA0-73C8-493B-95A0-AF18B898D619--