Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00

Olivier Bonaventure <> Fri, 24 July 2020 14:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 006703A094B for <>; Fri, 24 Jul 2020 07:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U4DCON6twNS2 for <>; Fri, 24 Jul 2020 07:17:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BEC23A095D for <>; Fri, 24 Jul 2020 07:17:10 -0700 (PDT)
Received: by with SMTP id j11so10138768ljo.7 for <>; Fri, 24 Jul 2020 07:17:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=My7eRWEQkkNYhVcU0HFKs/GxEbJ4qNj3dtCdcGaL1OE=; b=vQXBfojOmXcEeyncT/hhssyyVhYHBV5PqbvoG2ZYLwyzo8MgZwV4TlXPqgcWkvQjHg IzcUyJYzgOc9Huh5sbyKCUsbzfn5JdPTYuyqaYq7ZVBJFoyNwoe2xAXyoYk+LGyymKx7 idA1SFNjWVXjo9lqDyIBwsTB03pmdIRaxqb1c9hagULZmhJuJLmA/Icy/gCt8BYyi02Q ol0AcfBnHl8gIsV/hVWxSzFqgcNpqyA+S3v3kUKPGnXdt6dcaeJ5J758W1hnmHykujWc 4TkYKu03RSjt+sejzQHSwLbNXGQWHV9I4ttk1gOnJ1lgrs6ckT1ytCcg9+U1TPdEuqp9 U4MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=My7eRWEQkkNYhVcU0HFKs/GxEbJ4qNj3dtCdcGaL1OE=; b=QqTyfs1MuK+KjVhTL2E6RVDaYgQpBBFcmrUa51j2Ye8bYB7Y+Hh9gqQMC3J/Yp9g1E dT5s+kcGCDuS4rY/05YCnlgRVy4UxSYqpUcHThMol3I8joI0gBCfLLZAmqSvJTPhO0kU I/U7mTLGPxaoT9LWfV+RKQ3bQorHCkb/F93RwfWUrmQ3IZwhpRkJyZFQKWy/7zJjc9k6 LXp+WbXbtWLc9+oB0coAyO0TcuDT8FdgthfXNHvTdIFlfU79daGkofnqv6eI4XHuBn+m RpOyNOIX4QxDVhWHs4pv8L8yV2STDp1LhKtbX6PpC7rSFPnyR82J+b3Qwe1kBOwgEVuT BPuQ==
X-Gm-Message-State: AOAM530gohHL4cEnK0KkHittDLVNLTJVuSC8KXrSvko+ZTo0jirdUkmC 1+rTj8WhZ453IHl4zPmxW2sLeaQqzbq2nFyC9CFyKkgTSyuDTGqH9AHcYy1WBIIs29CfPAgMCAe 7OUbI8rxgUQxt
X-Google-Smtp-Source: ABdhPJxNWH9Ot7B4B6Itf28sHgsmx3iOGBVoeGxCQduI4InQB67OU+DPS30oLwOVqHZ63U/71iTJyaMjC+US9Zj06Vg=
X-Received: by 2002:a2e:9591:: with SMTP id w17mr4627274ljh.390.1595600228726; Fri, 24 Jul 2020 07:17:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <20200723144058.GQ73500@MacBook-Pro-64.local>
In-Reply-To: <20200723144058.GQ73500@MacBook-Pro-64.local>
From: Olivier Bonaventure <>
Date: Fri, 24 Jul 2020 16:16:42 +0200
Message-ID: <>
To: Christoph Paasch <>
Cc: Kangjiao <>, " Extensions" <>, Liangqiandeng <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jul 2020 14:17:17 -0000


> >
> > From my perspective, I think following are two different requirements:
> >
> > 1. Making all the traffic towards S2 (for this case, MP_PRIO may be enough)
> >
> > 2. Making traffic only from <IP_C1, IP_S1> to the destination IP_S2, which means diverting traffic that should be scheduled to <IP_C1, IP_S1> to one subflow belonging to the target network interface (it is "on-demand scheduling", for this case, MP_PRIO is not enough)
> What is the use-case for such a scheme?

Understanding the requirements from the applications would really help
in this discussion. This could also serve as input for Multipath QUIC
where the middlebox problems that are mentioned in the draft do not

> I don't see how a multipath scheduler could assign the traffic that "would"
> have been sent to <C1,S1> to a different subflow. Because for that he would
> need to know what *would* have been sent on <C1,S1> which he can only know
> once he actually sends traffic on that subflow as that will be driving the
> congestion-window which will allow to send more (or less) traffic on <C1,S1>.

Another point that needs to be taken into account is that when client
moves, the network conditions change dynamically and the server view
might differ from the wireless conditions on the client. In this case,
it is difficult for the server to precisely decide where it wants to
receive data. See