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

Yoshifumi Nishida <> Wed, 22 July 2020 07:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C7973A0E9D for <>; Wed, 22 Jul 2020 00:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mXVzAD-gWgCL for <>; Wed, 22 Jul 2020 00:21:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDB1D3A0E9C for <>; Wed, 22 Jul 2020 00:21:38 -0700 (PDT)
Received: by with SMTP id d11so624557vsq.3 for <>; Wed, 22 Jul 2020 00:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=umSxwOhnxJFGt/Y95BnTageorW/ylMYHaAEeKw6Agp8=; b=SBzWosuCNWS2PV1JdfCcn1yrajNoI0RwA3fv4VmzHko3q0zdBuQhhRF4Zgva+3hQ/O sweraTy6IyOjRHYjNlgDICkivy3Z2TeudTNv/x3hktNN9bKl3GBYvCWn+6HdgvesI26P 6x3EVF0yePX+X/Em5Z6LKH6O0KnIx2cb/DIsEL/0nVdnI4TRFISSu8klnY9IhFWPPhhY KoCfScGwXdMfO/dsfNrJ49NRnE8DXyCkcfFdEMb5LXnviJ/IVnpb3ozEMhk9blmZET4p He5bDF35kNIvykNNIen3aD/zpnFpVs1lIcMnJOhFQPVTmfIRc5rDEExOwP5KUQnXYFgJ KBSg==
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; bh=umSxwOhnxJFGt/Y95BnTageorW/ylMYHaAEeKw6Agp8=; b=TC1E+QxMbq05/1vcQ5Dkm0NxrZimXKLwZmKmihw72xDn6udsWCDPayzTYYOhUpzuSV rja99opjSM5C9we+A2WQ77lDvIRtGPEJAudhsp8+VcDdp8OhxPiTLF/kLNFaQW3Ffhy+ mOZ7agcqdr3/Y1t54hGY26qOGmnWLTXrKGFADhAtcI4kNlm3Bpw6dcAupEdlduNYnpYB yeJuO3K6ivK8Htxw5gRMOxrEV+gLg3urpUHx05HTfnRkGj1vvnV4leMxNydDwwLYOVKS dJfpCOoejBGUUkUw8fKuXBsT7coQed7ZDmAFMiwcDQ3oCbHEX4eUSJp93BLh8K1HX+OU ywpQ==
X-Gm-Message-State: AOAM530G9jFcGmZqGHl3LoYd7ryA4AQMqhlbG9NYJK8lreuXI3DbPDvd BIk0h12X1PDfAw1VKEX8WfC6SchndAwLV8vTen8=
X-Google-Smtp-Source: ABdhPJzzIrpz/l8ovVjqcvIMWm056Jq+t4poTW4ppeftsJu4BgQzHyNFDNz040POK0xu74xRWA0TWZRbd9NgKlTAsA8=
X-Received: by 2002:a67:f74a:: with SMTP id w10mr21353416vso.65.1595402496911; Wed, 22 Jul 2020 00:21:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Wed, 22 Jul 2020 00:21:25 -0700
Message-ID: <>
To: Kangjiao <>
Cc: " Extensions" <>, Liangqiandeng <>
Content-Type: multipart/alternative; boundary="0000000000001a2b2005ab0297ee"
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: Wed, 22 Jul 2020 07:21:40 -0000

Hi Kangjiao,

Thanks for the response.
I put my comments in lines.

On Sun, Jul 19, 2020 at 8:54 PM Kangjiao <> wrote:

> Hi Yoshi,
> Thanks for your suggestions. We clarify the issues as below:
> 1: One thing I'm not very clear is why we cannot use MP_PRIO for the use
> cases described in the draft. I believe the draft should describe the cases
> where existing features cannot fulfill the requirements more specifically.
> KJ: The new MP_Navigation Option is used for the server to indicate
> destination network interface to client for which server wants to use for
> traffic switching. For my understanding, MP_PRIO is used to signal a change
> in priority of subflows to the peer. In application, MP_PRIO can reduce the
> chance of data transmission on a specific subflow but it cannot tell its
> peer which network interface is the destination from server side. For
> example, if there are multiple subflows with high priority from difference
> network interfaces, client receiving MP_PRIO does not know which is the
> target one.

I think It would be better if you can show more concrete examples for the
scenario in the draft.
I would like to use the example in Section 3.2 of the draft for this. (BTW,
I personally prefer to use IP_C1 or IP_S1 or C1, S1 rather than IP1, IP2 so
that it will be easy to understand which address belongs to client or
If the server sends MP_PRIO with B flag to the client by using <IP1, IP3>
and <IP2, IP3>, I think the client will send traffic to IP4. Isn't this
what the server wants?

2: Clients also have their own constraints. (e.g. policy or routing) So,
> even though servers send a navigation request, they might not follow it. I
> think this point should be clarified.
> KJ: If the mechanism of accurate-data-scheduling-by-server is deployed,
> the principle is that the server takes precedence.

Well, let's say the server wants to use 5G because it's beneficial for
them, but the client doesn't want to use it because it's costly.
The client still should follow the server's request?

3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1?
> KJ:  For the protocol design, the definition of ’r’, ‘E’ and ’B’ are as
> following:
> Flag ‘r’: reserved for future usage.
> Flag ‘E’: exists to provide reliability for this option (like that in
> ”ADD_ADDR”).
> Flag ’B’: indicates whether the subflow over which the option is received
> is a backup one (that is compatiable with the value by MP_PRIO).
> But we are thinking whether these fields are necessary and should be set
> as mandatory.

Got it. Thanks for clarification. I think you'd better put these info into
the draft later.