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

Christoph Paasch <cpaasch@apple.com> Mon, 26 August 2019 17:31 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B3F120842 for <multipathtcp@ietfa.amsl.com>; Mon, 26 Aug 2019 10:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZBe8syyRY3K for <multipathtcp@ietfa.amsl.com>; Mon, 26 Aug 2019 10:31:25 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C751712008B for <multipathtcp@ietf.org>; Mon, 26 Aug 2019 10:31:25 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x7QHRBbG043483; Mon, 26 Aug 2019 10:31:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=20180706; bh=M0x5U0sDZEXEHMhEw3tiK+/da79+cMVyMCNmRHZdRz8=; b=RAghKyqipLA/5yyBeAciuZfOp7a1+K5qOCG11vOObA5tmB8P6+Cm/ZkFbkjXoNqtCYPu 1EM4DZz4jTjOWsxIvgGfWU+mp7sjTobtCJ/GZ/9SnqJeX8Xq+QhX7g+wb5fh3deS+K66 6rdHBe1wUGH01si7MLuTNbAMmCdZnBivohNbp6PbAoOv67sLBclzidhmnUC6o3oBlMbw 5suwptxXVCFDI2YZIL2uJOYxUSCB7FBctuKWYvCoWetYtMDfqUoepVWZ9L3A45jYZzgo kGURFfFRp7ojcbeIaeIKVJgGYBH2WF0VSe2QBFTwcNYmSGvJvI0oP/WuS5mCCIAXa0fs 2Q==
Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2uknfmth63-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 26 Aug 2019 10:31:24 -0700
Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PWU00BKQU0B42A0@mr2-mtap-s01.rno.apple.com>; Mon, 26 Aug 2019 10:31:23 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PWU00300TPUHL00@nwk-mmpp-sz10.apple.com>; Mon, 26 Aug 2019 10:31:23 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 772dd47e94105b6916a0f4f153438e87
X-Va-E-CD: aaf9a206e6a9da61f8e3973146981c7c
X-Va-R-CD: cac8f984c4dc83592c78d697d9fa2dd0
X-Va-CD: 0
X-Va-ID: 3343786c-a28c-4b93-9bb2-1bf27c4374b9
X-V-A:
X-V-T-CD: 772dd47e94105b6916a0f4f153438e87
X-V-E-CD: aaf9a206e6a9da61f8e3973146981c7c
X-V-R-CD: cac8f984c4dc83592c78d697d9fa2dd0
X-V-CD: 0
X-V-ID: bbc518bf-621b-44ff-89b8-6391ff6a5081
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-26_08:,, signatures=0
Received: from localhost ([17.192.155.217]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PWU001IGTZR8A10@nwk-mmpp-sz10.apple.com>; Mon, 26 Aug 2019 10:31:03 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Mon, 26 Aug 2019 10:31:03 -0700
From: Christoph Paasch <cpaasch@apple.com>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
Cc: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>, multipathtcp <multipathtcp@ietf.org>
Message-id: <20190826173103.GO5994@MacBook-Pro-64.local>
References: <CAAK044SMCwZbxTpvAxCmJiK6Di6BMpUSXVW2p0uwipwc2KyMxw@mail.gmail.com> <d5d0ca74-befd-0552-8a4d-670fc86b3648@uclouvain.be> <CAAK044RrG1Xc6Gpvdr80KMv2ZdETwjGVYTNdYRHtROHxdimLVA@mail.gmail.com> <192f0914-3f3a-9a76-71ec-059bf159d14c@uclouvain.be> <CAAK044R6qH_k7XwLhhQ8o=Cc4o_EEAtvxbx5LbE5LHGiOzODYw@mail.gmail.com> <20190821162948.GP5994@MacBook-Pro-64.local> <CAAK044SPkB2j9-GjWZYNhOf=kvanVwRQHVXBa9e0rF5E_tURAw@mail.gmail.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
In-reply-to: <CAAK044SPkB2j9-GjWZYNhOf=kvanVwRQHVXBa9e0rF5E_tURAw@mail.gmail.com>
User-Agent: Mutt/1.11.4 (2019-03-13)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-26_08:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/cX05KzczKS3R4Xt1Hve_OqaLFJk>
Subject: Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 17:31:28 -0000

Hello Yoshi,

On 26/08/19 - 00:31:20, Yoshifumi Nishida wrote:
> Hi Christoph,
> 
> On Wed, Aug 21, 2019 at 9:30 AM Christoph Paasch <cpaasch@apple.com> wrote:
> 
> > Hello,
> >
> > jumping in on this thread a bit late. Please see inline:
> >
> > On 16/07/19 - 23:31:57, Yoshifumi Nishida wrote:
> > > Hi Olivier,
> > >
> > > On Tue, Jul 16, 2019 at 2:31 AM Olivier Bonaventure <
> > > olivier.bonaventure@uclouvain.be> wrote:
> > >
> > > > Yoshi,
> > > >
> > > > >      > 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.
> > > >
> > > > Consider a video or audio streaming application running on a
> > smartphone.
> > > > Smartphone has WiFi and cellular but user wants to limit use of
> > cellular
> > > > and force server to use low quality when streaming over cellular.
> > > > When smartphone is attached to both WiFi and cellular, it can send SRL
> > > > with a bandwidth of 0 over cellular.
> >
> > Here, it would be nice to be able to close the cellular subflow. The reason
> > is the following: If we are not sending any packets on that cellular
> > subflow
> > (because we set the SRL to 0), after some time the subflow will become
> > dis-functional because the NAT/Firewall-mapping has expired.
> >
> > So, keeping subflows at 0 for an extended period will cause trouble.
> >
> 
> I think it's ok for an implementation to close the subflow here if they
> prefer.
> But, I am not sure if we need to standardize this behavior.
> 
> I think if the client really wants not to use cellular, it can just close
> the subflow by itself.

The problem is that the client can only do half-closed subflow by sending a FIN.

The way one would do this is: Set SRL to 0. Wait for quite a bit until
the subflow "calmed down". Send a FIN and see that the sequence-number in
the corresponding ACK of the peer is the same as the rcv_nxt [1]. This indicates
that the peer stopped sending. Now, the client can close the subflow with a
RST.

[1] If that's not the case, it means the peer hasn't reached SRL-0 yet. Now
the client can just wait and eventually kill the flow with a RST and hope
that no data-in-flight is being lost that way.

> I am guessing sending SRL 0 could mean something more. For example, the
> client wants to use the cellular for sending as it will send very small
> amount, but not for receiving due to the volume of data, or the client
> wants to stop using the cellular for a certain amount of time.  In the
> latter case, the client will need to send keep-alive at a certain period to
> avoid NAT timeout, though.

Agreed - that is the main use-case of SRL 0.


What is missing for my use-case is a way for the client to tell
the server to gracefully close the subflow. The reason for that can simply
be because WiFi has improved again and cell isn't needed anymore. The
current way to signal that is by killing the subflow with a RST which
results in loss of the in-flight-data. That loss degrades the overall
connection-quality as the data needs to be retransmitted over WiFi again.


Using SRL-0 is a half-baked way to get there. It allows to "calm down" the
subflow but isn't yet 100% safe as the client never knows when the server
actually reached the 0-rate.
Ideally, if we could use one of the reserved bits of the SRL-option
for that it would achieve the same goal.


Cheers,
Christoph