Re: QUIC - Our schedule and scope

[Quentin De Coninck <[e-mail]>]

Hello Igor,


Le 30/10/17 à 20:18, Lubashev, Igor a écrit :
>> https://www.ietf.org/internet-drafts/draft-deconinck-multipath-quic-00.txt
> My comment on this multicast design is that I do not think this ADD_ADDRESS can work well due to NATs (as the client is not aware of its external addresses).
This design is similar to the ADD_ADDRESS Multipath TCP option, and the 
current Multipath TCP deployments are using this to advertise the public 
addresses of the peer. The ADD_ADDRESS frame can be used to advertise 
other server public addresses, such that the NAT'd client can initiate 
path usage over those public addresses.

Quentin
>
> - Igor
>
> -----Original Message-----
> From: Olivier Bonaventure [mailto:[e-mail]]
> Sent: Monday, October 30, 2017 1:19 PM
> To: Spencer Dawkins at IETF <[e-mail]>; Eggert, Lars <[e-mail]>
> Cc: Lucas Pardue <[e-mail]>; Simon Pietro Romano <[e-mail]>; QUIC WG <[e-mail]>; Mark Nottingham <[e-mail]>; Quentin De Coninck <[e-mail]>
> Subject: Re: QUIC - Our schedule and scope
>
> Spencer,
>
>> When we were discussing the QUIC charter, I was very reluctant to
>> charter a new transport protocol in 2016 that didn't address multipath
>> (other people have suffered more while adding multipath to a protocol
>> that didn't anticipate multipath than I have, but I've seen enough
>> suffering). That may be the point I pressed on most strongly while
>> editing the current charter. So even though we wanted to minimize the
>> initial charter scope, I included multipath in the charter I took to
>> the IESG.
>>
>> I had assumed (without asking anyone) that
>>
>>      - Enabling multipath and forward error correction extensions
>>
>> (listed as one of the key goals in the current charter) would put
>> "making sure that extensions were possible" in scope for v1.
>
> Having spent many cycles at making sure that Multipath TCP can work and be deployed, I confirm that it is important to take multipath into account early in the design of a new protocol like QUIC.
>
> Quentin De Coninck has been working on Multipath QUIC and has submitted a draft that proposes minimal changes to QUIC v1 to support multipath capabilities. This could be a good starting point for the working group to ensure that the QUIC v1 design does not get stuck in a state where middlebox ossification makes multipath much more difficult than it should be.
>
> Name:		draft-deconinck-multipath-quic
> Revision:	00
> Title:		Multipath Extension for QUIC
> Document date:	2017-10-30
> Group:		Individual Submission
> Pages:		20
> URL:
> https://www.ietf.org/internet-drafts/draft-deconinck-multipath-quic-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/
> Htmlized:
> https://tools.ietf.org/html/draft-deconinck-multipath-quic-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-deconinck-multipath-quic-00
>
>
> Abstract:
>      Multipath TCP has shown how a reliable transport protocol can
>      efficiently use multiple paths for a given connection.  We leverage
>      the experience gained with Multipath TCP to propose simple extensions
>      that enable QUIC to efficiently use multiple paths during the
>      lifetime of a QUIC connection.
>
>
> The draft shows that with small extensions and the ability to encode a path identifier in the public header, it is possible to have a Multipath QUIC design that is both clean and extensible. Quentin also has an implementation of Multipath QUIC as an extension of the QUIC-go implementation (thus not totally aligned with QUIC v1). His measurements that will appear in a forthcoming paper show that Multipath QUIC provides very good performance compared with Multipath TCP.
>
>
> Best regards,
>
>
> Olivier Bonaventure
>