Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00

Yoshifumi Nishida <> Tue, 16 July 2019 06:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 011BC12018E for <>; Mon, 15 Jul 2019 23:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, 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 z8bOFmj6-R7T for <>; Mon, 15 Jul 2019 23:45:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8180112018B for <>; Mon, 15 Jul 2019 23:45:17 -0700 (PDT)
Received: by with SMTP id v15so17423297wml.0 for <>; Mon, 15 Jul 2019 23:45:17 -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=gc6myUVTblTN5g0z6Dt35gTJhpVORVoEqRbOAr3Aq90=; b=ijkIm0yIF30VT0qrd8DdGFjEjP+SomHI48EOWIha8d63+TkWo2duunYzfYx9vEdaBQ nRqN1yTXmVbbXZnu3+toYNaknR0Twenq/lRU2LFsR5AuJcixsdKx+39XEscxXYqLnPU5 MqvzmIq8rWLSw/NHo6M5ecEnkIEe607lJDF4vJEwdqEUdmPw5K3Szp5gUf2MOSsBVt28 bFP5HwftiDrQcgpYjflDHaAuAY6kiCpaklJpRc7I3vUZRhna+OPN8eGlMnjExtjvllti 7FN247DcNFO7DjZNSSg5kiSotVqWtMGOuzJcxRdDdoA4+iKkGOK6sDTUsWTsP1dV3gmY yqJQ==
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=gc6myUVTblTN5g0z6Dt35gTJhpVORVoEqRbOAr3Aq90=; b=V8vz/TTdoMyuE7a8R5q9PGIBCBjitAI1ZhS7ogxDJQNCp0bkyDYLrksa+SibrxlYOY 3vP4/ZhEtibYnEG8UrUsoekig7Fam1CAawF6A3A2bwm9JbWbG16EzM1gF++khByJiv1D 60UpWx8Kw2grrBO+BiGg2udRpGS6e3/mZQwqxNIXYWC0gwst+M2DCSgPv7Yr8IoA7RBd 7ywegxqbxdnZQ44yvEceTKM8O+yE3cqm1lCa8ROM7r8hFhabx4RriYCuunb58/m9loKN RmfufZYpVuctEOgWniDDQ89tV78HjDWLgE2wm/mr34GsA/vtW8w9q3uls4HOXbGEbJcv v81Q==
X-Gm-Message-State: APjAAAX/YFhEvH9Joamf3uaIIAeAsKWG2zh7DFNAY8kwDQ70mJK+D5XT CsdOYBoKj7hBnKYuLz5qMNQ+txdPw3nUBJY+bDc=
X-Google-Smtp-Source: APXvYqx63sEgnkelolNnnDBvlwht3K/gYvtQFRNpn4GFYkI9kExJAtulZtzR0FOfmlcpIrURZCVMPODZN9wJl4qYr/w=
X-Received: by 2002:a1c:7c11:: with SMTP id x17mr26593116wmc.22.1563259516068; Mon, 15 Jul 2019 23:45:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Mon, 15 Jul 2019 23:45:04 -0700
Message-ID: <>
To: Olivier Bonaventure <>, Viet Hoang Tran <>
Cc: multipathtcp <>
Content-Type: multipart/alternative; boundary="00000000000025a59b058dc6b862"
Archived-At: <>
Subject: Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jul 2019 06:45:20 -0000

Hi Olivier, Hi Viet,

Thanks for the explanations,

On Mon, Jul 15, 2019 at 8:53 AM Olivier Bonaventure <> wrote:

> Yoshi,
> > I've read this draft and have some questions and comments.
> Thanks for your comments.
> > 1: I am wondering how to calculate and limit the sending rate of subflow.
> >      I think adjusting window size wouldn't be very accurate. But, we
> > don't want to perform expensive processing for this purpose.
> The pragmatic approach is that it is possible to use window clamping and
> update the clamp value every time the rtt is updated. This is not as
> precise as a token bucket for example, but I don't think that the use
> cases that we have require this type of precision
> > 2: I think this is one way information and servers don't need to send
> > SRL option to clients. But, the draft says "a host MUST NOT send more
> > than three SRL options on connection where it has not received any SRL
> > option" Does this mean senders need to send SRL options?
> We'd like to limit the amount of SRL options that are sent, but another
> comment suggested to indicate a duration for the SRL value. This would
> require regular transmissions of the SRL option. This part of the text
> will need to be updated.

OK. I will wait for the updates.

> > 3: I am still not very sure the usage of SRL options for graceful
> > subflow closing. I might want to see some texts in the draft to
> > understand how this can be better than FIN exchange on subflows.
> When a client sends a FIN, it indicates that it will not send data
> anymore on this subflow. When it sends a SRL option with 0, it indicates
> to the server that it does not want to receive anymore data on this
> subflow. We can provide some text if we agree on this use case.

Right. I can image the following 3 situations on the client side.

1: client doesn't need to receive any more packets from server
2: client doesn't want sender to send more data, but wants to receive data
on the fly.
3: client wants to close the connection when sender finishes sending data

I think RST will work for 1: and we can use FIN for 3:.
So, in my understanding, this approach tries to address 2:.
I just would like to understand how much this kind of situations happen.