Re: [multipathtcp] Submitted drafts

Christoph Paasch <cpaasch@apple.com> Fri, 10 July 2015 17:36 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAAC1A020D for <multipathtcp@ietfa.amsl.com>; Fri, 10 Jul 2015 10:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 QPlhVnhXoM6U for <multipathtcp@ietfa.amsl.com>; Fri, 10 Jul 2015 10:36:01 -0700 (PDT)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3771D1A01D6 for <multipathtcp@ietf.org>; Fri, 10 Jul 2015 10:36:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1436549760; x=2300463360; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fJxZZqXCntN1CXwyG3hQVOlCFUSt1TgHtz9zoW+nGOc=; b=TqWhNurHth7KG3xqc1zOIArj05NUBJI+G7iQ63AdTKY3xu8IT0h286RSj/YyN3bt zy54EOIxgZ2dwsELw5JT7sRKr7koIrO4RB8wRY6hiCog7LITcSDW95en0TGTEZlo XPdvZoJRNbLrdaE0mw3o5Lhb+kz71bbT6U/cBnzqZ/vXwv+jmRHXfu46pWSXanVA ChRLN/e4LH/TSYKjDxwg/Egkxo3heAHliISEdztTM21+gkNzbYJ/YAV3Nj8xB3y4 jqJQ+2qfm9mzbaopk/88+v4x9b+fJQmKKQuyUSh8v50bxCcdDg4SRBB58S1wUFT4 4PmswafkLi6TLS4OvZJmBA==;
Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 39.2B.18963.08200A55; Fri, 10 Jul 2015 10:36:00 -0700 (PDT)
X-AuditID: 11973e12-f79456d000004a13-96-55a002807bc4
Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 15.4D.13288.08200A55; Fri, 10 Jul 2015 10:36:00 -0700 (PDT)
Received: from localhost ([17.226.23.204]) by fenugreek.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NRA005GL8W0NK60@fenugreek.apple.com> for multipathtcp@ietf.org; Fri, 10 Jul 2015 10:36:00 -0700 (PDT)
Date: Fri, 10 Jul 2015 10:36:00 -0700
From: Christoph Paasch <cpaasch@apple.com>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-id: <20150710173600.GO1144@Chimay.local>
References: <559E8D85.2060603@uclouvain.be> <cdbfab2b826949a5bf4f824358a995dc@rew09926dag03b.domain1.systemhost.net> <559F65C6.8030305@uclouvain.be>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-disposition: inline
In-reply-to: <559F65C6.8030305@uclouvain.be>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FDorNvAtCDU4EGPlsXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsW3ZYpaCVoGK2y9uMTcwdvB2MXJySAiYSKy4spoNwhaTuHBv PZDNxSEksJdR4vmNlewwRfPWbGUEsYUEJjNJTDyYBVHUzyTxtvsOWIJFQFXi19XjLCA2m4CW xNvb7awgtoiAlcSp09PBBjELGEgsnXMRyObgEBbQkbj9SgQkzAsUnjhnDSvEzBlAi3dtZoJI CEr8mHyPBaJXS2L9zuNMELa0xKO/M8BmcgLNuXr1I9guUQEViSsT3rKDDJIQeMsq8fPZJ5YJ jMKzkMyahWTWLCSzFjAyr2IUyk3MzNHNzDPRSywoyEnVS87P3cQICuTpdkI7GE+tsjrEKMDB qMTDG8A2P1SINbGsuDL3EKM0B4uSOO+fK/NChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTD2 bq1Pb9vKyHTt2P4nt00OHH/8Ly0mb8njOaX3XC6c+/KNu+VE+qHOF8pLHZ6cX3Eozm1Cur+a +bOg9G+3M48t33R6olRtb8trLbfs+GiVTTwVf9/XXtkWcfGBwWz9DaevdpXOMSx7EfLIOVT8 xMuUwM/z9pSz2HLIaa7c1br58Y7Vb8+cPD6zRomlOCPRUIu5qDgRAL7gXcRFAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCcqNvAtCDUYOFVVYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9uyxSwFrQIVt1/cYm5g7ODtYuTkkBAwkZi3ZisjhC0mceHe ejYQW0hgMpPExINZXYxcQHY/k8Tb7jtgRSwCqhK/rh5nAbHZBLQk3t5uZwWxRQSsJE6dns4O YjMLGEgsnXMRyObgEBbQkbj9SgQkzAsUnjhnDSvEzBmMEs93bWaCSAhK/Jh8jwWiV0ti/c7j TBC2tMSjvzPAZnICzbl69SPYLlEBFYkrE96yT2AUmIWkfRaS9llI2hcwMq9iFChKzUmsNNJL LCjISdVLzs/dxAgOvELnHYzHllkdYhTgYFTi4Q1gmx8qxJpYVlyZe4hRgoNZSYS3exVQiDcl sbIqtSg/vqg0J7X4EKM0B4uSOK/mlCmhQgLpiSWp2ampBalFMFkmDk6pBkb/QB01DZs+uePP faZlF3czdixhePrWbdK10Pq5rocbyk02M7QfKhQLCxcUkaw4vXjtM983iRYrre68klysvsV0 47GUDzM+SP5vznnqWnHRlV8u5Bf7wvNzcxPjXsRf2pLwvHu69p9ZM+eq+0v8Wt1tunzVOXF/ nVQxLq2O20e4ppfJ1e8+NUmJpTgj0VCLuag4EQDtAUMXOAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/multipathtcp/X3oAY1maFKcYQJZvvWCX9zeSnKE>
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Submitted drafts
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jul 2015 17:36:02 -0000

Hello,

On 10/07/15 - 08:27:18, Olivier Bonaventure wrote:
> >Thanks for all the work.
> >
> >Please comment on the drafts - for instance, what things are worth adding to the protocol bis?
> >
> 
> >>*
> >>https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-
> >>option-00.txt
> 
> This draft would be a good candidate to be included in RFC6824bis.

+1

> >>https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp-
> >>01.txt
> >>
> >>This is an example of the utilisation of experimental options to encode
> >>a timestamp option
> >>
> >>* https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr-
> >>00.txt
> 
> This draft includes a slight modification of the handling of the address
> identifier for the initial subflow. Comments from other implementors would
> be useful on this draft.

I agree with section 2.1 that having a different address-ID for the
initial subflow is very cumbersome. An implementation has to store the local
address-id's within the state-machine of each subflow. It would be much
easier if we could have a fully global address-table.

However, I'm not sure whether it is good to solve it through an empty
ADD_ADDR-option. Because, the option is not sent reliably. Even if it gets
combined with data, we have an issue with unidirectional streams. And
communicating this ADD_ADDR-option reliably to the peer is here in this case
even more important than for the "regular" ADD_ADDR option.

It would be better if we could put the address-ID inside the MP_CAPABLE.
Maybe we can use 8 bits of the key?



(also, a little nit: Adding the IPVer within this ADD_ADDR-option is not
necessary and will bring issues in NAT64-environments).


Cheers,
Christoph


> 
> The other drafts are more improvements that do not necessarily need to go
> into rfc6824bis
> 
> 
> Olivier
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp