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

Kangjiao <> Mon, 03 August 2020 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A00B3A0E8B for <>; Sun, 2 Aug 2020 18:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pA0HXVV4xZkz for <>; Sun, 2 Aug 2020 18:09:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76C823A0E89 for <>; Sun, 2 Aug 2020 18:09:57 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 912213775DF7B5FA6BD7 for <>; Mon, 3 Aug 2020 02:09:54 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 3 Aug 2020 02:09:54 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 3 Aug 2020 02:09:53 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Mon, 3 Aug 2020 09:09:45 +0800
From: Kangjiao <>
To: Christoph Paasch <>
CC: Olivier Bonaventure <>, " Extensions" <>, Liangqiandeng <>
Thread-Topic: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00
Date: Mon, 3 Aug 2020 01:09:45 +0000
Message-ID: <>
References: <> <> <> <20200723144058.GQ73500@MacBook-Pro-64.local> <> <> <20200727165822.GB73500@MacBook-Pro-64.local>
In-Reply-To: <20200727165822.GB73500@MacBook-Pro-64.local>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Mon, 03 Aug 2020 01:09:59 -0000

Hello Christoph,

Currently we have no pseudo-code example for you. We are planning to implement and test it in our system but I cannot promise the timeline for this development because of some undetermined factors.

Before that, I think we can discuss and clarify all related use cases/requirements to it for further solution and protocol design.

>From our side, adjusting the weights and preferences on the subflows may be not enough to ensure that all traffic is transmitted along the specified network interface as the analysis in previous mails.


-----Original Message-----
From: Christoph Paasch [] 
Sent: Tuesday, July 28, 2020 12:58 AM
To: Kangjiao <>
Cc: Olivier Bonaventure <>et>; Extensions <>rg>; Liangqiandeng <>
Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00

On 07/25/20 - 15:18, Kangjiao wrote:
> The scenarios in this draft are not for traffic handover when 
> encountering network failure. It is applied when one peer has an 
> explicit plan on traffic switching. For example, for network migration 
> or expansion on server, operator wants to adjust the traffic on these networks in advance.
> This is an actual case.
> We think packet scheduler knows on which subflow the next packet will 
> be sent.
> So it may be a good choice to deploy the logic of accurate traffic 
> switching on this component.

I would love to understand more on how one would implement such kind of a logic. Do you have a pseudo-code example? I have a hard time imagining how the scheduling estimates the amount of traffic it would have sent on subflow A and rather sends it on subflow B, because to drive this decision-making it needs an estimate of RTT, congestion-window,... of subflow A which it only can get by actually scheduling traffic on A.

While at a macro-level an operator can do its traffic-engineering and decide what proportion of traffic should be sent on one vs the other path, I don't see how this translates into the same method at the micro-level where scheduling happens on a packet-by-packet basis and is hugely driven by congestion-control and RTT.

Thus, to achieve such traffic-engineering for the operator it looks to me like it translates rather to adjusting the weights and preferences on the subflows.


> Sincerely,
> Jiao
> -----Original Message-----
> From: Olivier Bonaventure []
> Sent: Friday, July 24, 2020 10:17 PM
> To: Christoph Paasch <>
> Cc: Kangjiao <>om>; Extensions 
> <>rg>; Liangqiandeng <>
> Subject: Re: [tcpm] comments on 
> draft-kang-tcpm-accurate-data-scheduling-by-server-00
> Hello,
> > >
> > > 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 exist.
> > 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
> Olivier
> --
> Disclaimer:
> <>