Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Christoph Paasch <cpaasch@apple.com> Fri, 13 December 2019 18:24 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 C026E12010C for <multipathtcp@ietfa.amsl.com>; Fri, 13 Dec 2019 10:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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 69MvXVEkdlFf for <multipathtcp@ietfa.amsl.com>; Fri, 13 Dec 2019 10:24:18 -0800 (PST)
Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.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 EC0D7120013 for <multipathtcp@ietf.org>; Fri, 13 Dec 2019 10:24:17 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id xBDIHOhM038976; Fri, 13 Dec 2019 10:24:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : date : from : to : cc : subject : message-id : references : in-reply-to; s=20180706; bh=KsxEtMNFojLtdFWF/iEpDdRKxhu8NQi1rqtgo+8cTUw=; b=AU0o3U1Yem3n5OSBjeFxZTI2d0r4GwkuGGYL0g0mBqsfxEv9HLWUhn/DBWoi/s9SpQwM bpZkjovgjCHt48Y4ZHo4llUu6yUl2ctVZIg0tv+m6e9+EUJ2cp5hUBAM5bzzPnOiH7jS EGWJloCE/lPbJwE9KAo1Lth3DQ1Sabw1zQRIhNVZ1tFM0FKGTQU/6JLv2lNeF3cHA/X/ ippWSQGx1LaS5WjdCv51YSR6jBSwMstKqggZv4nfaPiy7P4dab9HWidzdaRatfm/C6eu pMAPPELbcbHKp1J+fgWB9FeMqKU6jgaM14Q21QB2QwGt/7E6CMEJeGW0yAzo+2scv5XN Wg==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2wr9n0bf82-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Dec 2019 10:24:10 -0800
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q2G00FJBR49JB60@ma1-mtap-s02.corp.apple.com>; Fri, 13 Dec 2019 10:24:10 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q2G00100QUKEF00@nwk-mmpp-sz09.apple.com>; Fri, 13 Dec 2019 10:24:09 -0800 (PST)
X-Va-A:
X-Va-T-CD:
X-Va-E-CD:
X-Va-R-CD:
X-Va-CD: 0
X-Va-ID: 6702dee6-f8fd-4921-a745-98e9bfee847f
X-V-A:
X-V-T-CD: 180e5e1b6a6fda3f9ba414022b920652
X-V-E-CD: 1267ad930a5510df15e8bf1401474564
X-V-R-CD: d1bec3bf3ba8d66d42ac99ad7d4c4b7f
X-V-CD: 0
X-V-ID: d1c91203-6aa6-4907-a55b-b1cd631513d3
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-12-13_05:,, signatures=0
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=utf-8
Received: from localhost ([17.230.196.189]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q2G00B1WR49A100@nwk-mmpp-sz09.apple.com>; Fri, 13 Dec 2019 10:24:09 -0800 (PST)
Sender: cpaasch@apple.com
Date: Fri, 13 Dec 2019 10:24:09 -0800
From: Christoph Paasch <cpaasch@apple.com>
To: V Anil Kumar <anil@csir4pi.in>
Cc: Alan Ford <alan.ford@gmail.com>, MultiPath TCP - IETF WG <multipathtcp@ietf.org>, mptcp Upstreaming <mptcp@lists.01.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
Message-id: <20191213182409.GB9430@MacBook-Pro-64.local>
References: <f97420243acd.5df3748a@nic.in> <42684CE4-7B3E-4899-9706-7E3AAB39A9F7@apple.com> <fb16f29f7ecc.5df421a5@nic.in>
In-reply-to: <fb16f29f7ecc.5df421a5@nic.in>
User-Agent: Mutt/1.12.2 (2019-09-21)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-13_05:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Ll_eYE4ivmsNe2V8SkVPcanz9PE>
Subject: Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
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: Fri, 13 Dec 2019 18:24:20 -0000

On 13/12/19 - 23:41:25, V Anil Kumar wrote:
> Hi Christoph,
> 
> Thanks again for your reply. My response is given inline.
> 
> On 12/13/19 09:59 PM, Christoph Paasch  <cpaasch@apple.com> wrote: 
> > 
> > 
> > 
> > 
> > 
> > 
> > Hello,
> > 
> > 
> > 
> > > On Dec 12, 2019, at 9:53 PM, V Anil Kumar <anil@csir4pi.in> wrote:
> > > 
> > > 
> > 
> > 
> > > 
> > >  Hi Christoph,
> > > 
> > > Thanks for your reply. Please see inline.
> > > 
> > > On 12/12/19 12:52 AM, Christoph Paasch  <cpaasch@apple.com> wrote: 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > On Dec 10, 2019, at 12:04 PM, V Anil Kumar
> > > > > <anil@csir4pi.in(javascript:main.compose()> wrote:
> > > > > 
> > > > > 
> > > > > Hi Alan, 
> > > > > 
> > > > > 
> > > > > 
> > > > > Please see inline.
> > > > > 
> > > > > On 12/06/19 09:28 PM,Alan
> > > > > Ford<alan.ford@gmail.com(javascript:main.compose()> wrote: 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Following on from the discussion of implementation feedback with
> > > > > > Christoph, I propose the following edits to RFC6824bis - which
> > > > > > is currently in AUTH48 - as clarifications.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ADs, please can you confirm you consider these edits
> > > > > > sufficiently editorial to fit into AUTH48.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > WG participants, please speak up if you have any concerns.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Edit 1, clarifying reliability of MP_CAPABLE
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Change the sentence reading:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  The SYN with MP_CAPABLE occupies the first octet of data
> > > > > >  sequence space, although this does not need to be acknowledged
> > > > > >  at the connection level until the first data is sent (see
> > > > > >  Section 3.3).
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > To:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  The SYN with MP_CAPABLE occupies the first octet of data
> > > > > >  sequence space, and this MUST be acknowledged at the connection
> > > > > >  level at or before the time the first data is sent or received
> > > > > >  (see Section 3.3).
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Change the sentence reading:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  If B has data to send first, then the reliable delivery of the
> > > > > >  ACK + MP_CAPABLE can be inferred by the receipt of this data
> > > > > >  with an MPTCP Data Sequence Signal (DSS) option (Section 3.3). 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > To:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  If B has data to send first, then the reliable delivery of the
> > > > > >  ACK + MP_CAPABLE is ensured by the receipt of this data with an
> > > > > >  MPTCP Data Sequence Signal (DSS) option (Section 3.3)
> > > > > >  containing a DATA_ACK for the MP_CAPABLE (which is the first
> > > > > >  octet of the data sequence space).
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > In my personal opinion either one of these edits would be
> > > > > > sufficient for making the point, however clearly this has caused
> > > > > > some confusion amongst the implementor community so making both
> > > > > > these changes should make it absolutely clear as to the expected
> > > > > > behaviour here.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Edit 2, mapping constraint
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Change the sentence reading:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  A Data Sequence Mapping does not need to be included in every
> > > > > >  MPTCP packet, as long as the subflow sequence space in that
> > > > > >  packet is covered by a mapping known at the receiver.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > To:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  A Data Sequence Mapping MUST appear on a TCP segment which is
> > > > > >  covered by the mapping. It does not need to be included in
> > > > > >  every MPTCP packet, as long as the subflow sequence space in
> > > > > >  that packet is covered by a mapping known at the receiver.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > 
> > > > > As far as I understand, the proposed change introduces a “MUST” to
> > > > > insist that the map in a segment must cover at least some data in
> > > > > the segment. But the document does not talk anything about the
> > > > > rational behind it. I guess it is purely an 
> > > > > 
> > > > > ease of implementation?
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > For two reasons:
> > > > 
> > > > 1. Ease of implementation 2. If an implementation tries to
> > > > "remember" early mappings, it is not clear how many of these an
> > > > implementation can hold. Thus, the sender does not know how many
> > > > early mappings he can send. So, it is hard for a sender to do the
> > > > right thing.
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > I think the design/format of the Data Sequence Mapping permits the
> > > > > map to stand independent of the data being carried in a segment.
> > > > > So, as long as an implementation is willing to deal with the
> > > > > complexity of storing and processing late and early mappings (with
> > > > > respect to the data arrival), it could be permitted provided that
> > > > > the received map is for an in-window data.
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > What is the concrete use-case for such early mappings? What are the
> > > > benefits of it? I think that if we want to enable such
> > > > implementation-complexity, we need a compelling use-case with a big
> > > > benefit.
> > > > 
> > > > 
> > > >  
> > > > 
> > > 
> > > Consider a case where a MPTCP connection consists of two subflows, and
> > > the data segments are scheduled for transmission in the order shown
> > > below below.  
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > Subflow-1: segment-1 segment-3 segment-5 segment-6 
> > > 
> > >  bytes:1-100 bytes:201-300 bytes:401-500 bytes:501-600 
> > > 
> > >  no map map for 1-100 map for 401-600 no map 
> > > 
> > > 
> > >  
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > Subflow-2: segment-2 segment-4 segment-7 segment-8 
> > > 
> > >  bytes: 101-200 bytes:301-400 bytes: 601-700 bytes:701-800  
> > > 
> > >  map for 101-200 map for 301-400 map for 601-800 no map 
> > > 
> > >   
> > > 
> > > In the above case, the map for data in segment-1 is included in
> > > segment-3. 
> > > 
> > > 
> > > 
> > 
> > 
> > The question here is why would the stack not put the mapping for segment
> > 1 on segment 1 itself. And what is the benefit of doing so?
> > 
> > 
> > 
> >  
> > 
> 
> Well it could just be due to the lack of option space insegment-1. For
> example, the sender ofsegment-1 at that instant wants to transmit multiple
> TCP options (e.g.timestamp, SACK, DSS and ADD_ADDR). Obviously, they all
> cannot fit into optionfield of one segment, and eventually the DSS
> transmission got slightly delayedby a segment or two.

The implementation needs to enforce a strict priority of DSS over SACK and ADD_ADDR.

If the ADD_ADDR does not fit in the TCP-option space, it can send the
ADD_ADDR on a pure ACK. The echo-bit in the ADD_ADDR guarantee the reliable
delivery of it.


Sure, one could argue that favoring SACK over DSS is more important. But I
think we would need data to justify that. Only very specific traffic
patterns will fall in this use-case.


Christoph

> 
>  
> 
> With regards,
> 
>  
> 
> Anil
> 
>  
> 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Christoph
> > 
> > 
> > > 
> > > 
> > > 
> > > Further, segment-3 cannot combine/cover the data in segment-1 and segment-3 in a "single map", as the data sequence space is not continuous, i.e., some in between data (segment-2) is mapped and transmitted through subflow-2. Here, the map in segment-3 does not even partially cover the data it carries. 
> > > 
> > > 
> > >  
> > > 
> > > Both RFC 6824 and the 6824-bis do not restrict the above scenario, and I guess the change proposed now does not permit this to happen. 
> > > 
> > > 
> > >  
> > > 
> > > Best regards, 
> > > 
> > > 
> > >  
> > > 
> > > Anil 
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > That's the reason why we (the MPTCP-upstreaming community) vouch to have this case restricted.
> > > > 
> > > > 
> > > > 
> > > > Cheers,
> > > > Christoph
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Anil 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Best regards,
> > > > > > 
> > > > > > Alan
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> >  
> >