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

Christoph Paasch <cpaasch@apple.com> Wed, 21 August 2019 16:30 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 103C5120C32 for <multipathtcp@ietfa.amsl.com>; Wed, 21 Aug 2019 09:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, URIBL_BLOCKED=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 vRUmGcXlD7mb for <multipathtcp@ietfa.amsl.com>; Wed, 21 Aug 2019 09:30:08 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 255F1120BD2 for <multipathtcp@ietf.org>; Wed, 21 Aug 2019 09:30:08 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x7LGROJ5038164; Wed, 21 Aug 2019 09:30:05 -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=5DopQ8RpSkdemc53Q/PzAwcUKZ0VIufbvRYLmt6FwGc=; b=PzmJW5O/Ar+1Ygmf2L/CIqWbmA0ueAA33SC7ff/qC9RQMB7LYNGpDow4bB7ULmbwH5sB nghKBjsG7B2f4QecbRVTZJYSl1vrs6HrHkgfdNvGdZe67xXc9B0rE6M7CsBffL0cWAth Wy0kf6EQsfovwXSJuWGiuBttWa6jLglASeNekK6XTUWgV67qjGZn5w8hP2pytC/0POh/ yieAGrd/kFKe3AwDuKHRAdT2hWbIrtH7dukHXS4ohbcUtL2RZT1T4HT+7taocZUX7e5C 0gBzrowyJvzTzOSh5BRJybkN5KlxSw3OJhLzI/UXIp7ln9pNN332pcAF0jGEnry6+aZk 4Q==
Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2uegk10py9-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 21 Aug 2019 09:30:05 -0700
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PWL00K5PHU4D480@mr2-mtap-s03.rno.apple.com>; Wed, 21 Aug 2019 09:30:04 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PWL00600HTZRE00@nwk-mmpp-sz13.apple.com>; Wed, 21 Aug 2019 09:30:04 -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: 426a8057-bdff-4ef5-a9ec-263b50fdefdc
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: d30fb3a8-2e5a-4d8f-9e73-150953b5c957
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-21_05:,, signatures=0
Received: from localhost ([17.192.155.217]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PWL005FLHTPW6C0@nwk-mmpp-sz13.apple.com>; Wed, 21 Aug 2019 09:29:49 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Wed, 21 Aug 2019 09:29:48 -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: <20190821162948.GP5994@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>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
In-reply-to: <CAAK044R6qH_k7XwLhhQ8o=Cc4o_EEAtvxbx5LbE5LHGiOzODYw@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-21_05:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/K6qiGRUqSK-JGSQHuMb3S1gukYM>
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: Wed, 21 Aug 2019 16:30:10 -0000

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.

> > If the smartphone moves, and leaves WiFi, then it could send a SRL at 1
> > Mbps to limit throughput.
> >
> > This dynamic control of the throughput on the incoming subflows would
> > work well if a client can adapt its SRL to the current network conditions.
> >
> 
> OK. I think this would be a nice example for the usages of SRL and I
> understand.
> But, I am thinking that it might not be helping graceful closing much.
> Anyway, the closing is not a major part of the draft. I personally think
> removing it might be a choice when we don't have strong use cases.

Could the SRL-option have a bit that says "and when you reached 0-rate,
please close the subflow" ?

Sure, we could simply on the receiver-side, wait until the subflow quiesces
and then close it with a RST. However, if that RST gets lost, the subflow
will hang on the sender-side for quite a while.


Cheers,
Christoph