IETF Logo Mail Archive

Re: RTGWG WGLC draft-ietf-rtgwg-enterprise-pa-multihoming

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Tue, 17 April 2018 07:23 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4CF12711B; Tue, 17 Apr 2018 00:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 JqpLDveKKFO3; Tue, 17 Apr 2018 00:23:38 -0700 (PDT)
Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8528E12EB48; Tue, 17 Apr 2018 00:23:38 -0700 (PDT)
Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A5EEB67E07C; Tue, 17 Apr 2018 09:23:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1523949805; bh=A2e61C8VxToyE/7FxPcZFcaqvOkJ3+zzbbapWogsXbE=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To:From; b=w6m9ZTrg928J66jVIyKe1zB6coT4J3ppzqe+4TWnuhQEqZkMcYJVQ5zKczuqh4TjM zIuv2Tw2K88WTH3i14wL/up22ZBiDXTwJou2sVzap7ATcZcpL3TYyg83Ct4IEhjBrU UZDm7A/I4GI2ShejraEqUe72b94d6cgkqZyMBnhM=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.3-beta2 at smtp-3.sipr-dc.ucl.ac.be
Reply-To: Olivier.Bonaventure@uclouvain.be
Subject: Re: RTGWG WGLC draft-ietf-rtgwg-enterprise-pa-multihoming
To: Jeff Tantsura <jefftant.ietf@gmail.com>, RTGWG <rtgwg@ietf.org>
Cc: rtgwg-chairs <rtgwg-chairs@ietf.org>
References: <44C0D21A-9788-4AEE-B814-D3670D3B3110@gmail.com>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <f3a6a3d5-9aaf-54dd-edfc-dd58d223afde@uclouvain.be>
Date: Tue, 17 Apr 2018 09:23:25 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <44C0D21A-9788-4AEE-B814-D3670D3B3110@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr-classic
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: A5EEB67E07C.A811B
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/5bQ0CXaIc5lgRuvjJOvIaHx-rEg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2018 07:23:44 -0000

Jeff, RTGWG,
> 
> The authors have requested the RTGWG to last call 
> draft-ietf-rtgwg-enterprise-pa-multihoming.
> 
> There was consensus that document is ready for the last call and the 
> authors have resolved all the comments received from the v6ops reivew.

The document discusses a range of solutions to enable legacy hosts to 
select the right source address to use to reach a given destination. 
However, I think that it complety ignores a very clean and efficient 
solution to the multihoming problem : using multipath transport. The 
IETF has already approved Multipath TCP in RFC6824. It is widely 
deployed on one popular brand of smartphones and the MPTCP working is 
progressing towards a standards-track version of MPTCP. In parallel, the 
charter of the QUIC working group includes multipath support and there 
is already an implementation which is available (see 
https://www.multipath-quic.org). Multipath RTP has already been 
discussed within the IETF as well.

With Multipath transport, the entreprise pa multihoming problem can be 
solved in a much cleaner manner. A multipath transport has much more 
flexibility in a multihomed site than a single path transport protocol. 
With a multipath transport, it is possible to :
- select a source address at the beginning of a connection and switch to 
another one during the lifetime of the connection without breaking it
- use multiple source addresses for a given connection to achieve best 
performance (low delay, higher bandwidth by bonding, ...)
- learn a new source address when a link comes up and use it during a 
connection
- react to congestion on one uplink by switching traffic to the other 
uplinks


I think that it would make sense to either :
- discuss the impact of multipath transport in the current document (the 
draft lists [I-D.ietf-mptcp-experience] in its references but does not 
cite it in the text)
- indicate that the current document is restricted to single path 
transport and write another document that describes how multipath 
transport protocols can be used to solve the problems listed in this 
document

I'm happy to contribute if the WG decides to go in either of these 
directions.

Best regards,


Olivier Bonaventure

v2.23.0 | Report a Bug | By Email