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

Kangjiao <> Sat, 25 July 2020 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 880FC3A0AA0 for <>; Sat, 25 Jul 2020 08:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ph6w97z7wdqo for <>; Sat, 25 Jul 2020 08:18:42 -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 A921F3A0A83 for <>; Sat, 25 Jul 2020 08:18:42 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id A6CB7E14F3A01276F11D for <>; Sat, 25 Jul 2020 16:18:39 +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; Sat, 25 Jul 2020 16:18:39 +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; Sat, 25 Jul 2020 16:18:39 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Sat, 25 Jul 2020 23:18:29 +0800
From: Kangjiao <>
To: Olivier Bonaventure <>, Christoph Paasch <>
CC: " Extensions" <>, Liangqiandeng <>
Thread-Topic: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00
Date: Sat, 25 Jul 2020 15:18:28 +0000
Message-ID: <>
References: <> <> <> <20200723144058.GQ73500@MacBook-Pro-64.local> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: Sat, 25 Jul 2020 15:18:45 -0000


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.


-----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


> >
> > 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