RE: QUIC - Our schedule and scope

"Lubashev, Igor" <ilubashe@akamai.com> Mon, 30 October 2017 19:19 UTC

Return-Path: <ilubashe@akamai.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505AA138D8F for <quic@ietfa.amsl.com>; Mon, 30 Oct 2017 12:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=akamai.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 QGG9-E9MDF79 for <quic@ietfa.amsl.com>; Mon, 30 Oct 2017 12:18:59 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 2F399138A38 for <quic@ietf.org>; Mon, 30 Oct 2017 12:18:59 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9UJFbX1010885; Mon, 30 Oct 2017 19:18:54 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dtmw30RFT8ZmSLucktHftWRtDEMTxYwW+vOGdeayhYQ=; b=MytE8JZ8pdFFXDqzXVrg4ee9C5Nl6++fqQcJeXgnOthYFhfvVoACQpOduxL7deUYEOFx YY5JCqv4Px8LQwX3QshhX5Wl4Vo1M9pEw39OVjb6TluSVUKkwpZTiOzj48ll1dx3DKte xotSmvVoONAq6xki45CB3RWuESQ+C1cxl9lEq9ECMbxSJxO1TMA5AawjRpa7yUtsj9tA 8BMiMPxvqGJ8w3ROeqBdE9XK1fAgR7qwUj3tWX+69Ld5NojYohJ9ob2KQYX3lCP18+3k 8tYwrRAHs9A6Mo6o09nh6uYHpUdtznpQdxizhC3wYBqj/TLe7uf/uEO2usyReSVc4Kah dg==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2dvmwdfxfg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 19:18:54 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9UJD3Gv029217; Mon, 30 Oct 2017 15:18:51 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7twv9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 15:18:51 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 30 Oct 2017 12:18:51 -0700
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 30 Oct 2017 15:18:50 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Mon, 30 Oct 2017 15:18:50 -0400
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Olivier Bonaventure <olivier.bonaventure@tessares.net>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "Eggert, Lars" <lars@netapp.com>
CC: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, Simon Pietro Romano <spromano@unina.it>, QUIC WG <quic@ietf.org>, Mark Nottingham <mnot@mnot.net>, Quentin De Coninck <quentin.deconinck@uclouvain.be>
Subject: RE: QUIC - Our schedule and scope
Thread-Topic: QUIC - Our schedule and scope
Thread-Index: AQHTTuyf6V6ciOlU90OGaSvkCp/hUKL4KMmAgABqWgCAAhmSAIAAF1WAgAElBwCAAQKUgP//yE5A
Date: Mon, 30 Oct 2017 19:18:50 +0000
Message-ID: <54d92bde12844ec1a2d470bd1982f66e@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net> <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> <FAE9A7F7-C642-4AC5-B469-91BE7189F2F0@unina.it> <FFBE48EA-FD6F-42C6-B1A4-80C4CD8D9864@netapp.com> <CAKKJt-e1K1LD=P217oGZ2XDmWFaLp3tmwXmYOxh+Mud+zdM3bA@mail.gmail.com> <d0218dba-288e-1d0a-f0d2-e9996a53c650@tessares.net>
In-Reply-To: <d0218dba-288e-1d0a-f0d2-e9996a53c650@tessares.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.35.213]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-30_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710300255
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-30_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710300255
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ehaGsDFF98W-fDATlgazYxL3cq4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 19:19:01 -0000

> 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).

- Igor

-----Original Message-----
From: Olivier Bonaventure [mailto:olivier.bonaventure@tessares.net] 
Sent: Monday, October 30, 2017 1:19 PM
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; Eggert, Lars <lars@netapp.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; Simon Pietro Romano <spromano@unina.it>; QUIC WG <quic@ietf.org>; Mark Nottingham <mnot@mnot.net>; Quentin De Coninck <quentin.deconinck@uclouvain.be>
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

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.