Re: New Version Notification for draft-huitema-quic-mpath-option-01.txt

Christian Huitema <huitema@huitema.net> Wed, 15 September 2021 18:37 UTC

Return-Path: <huitema@huitema.net>
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 5F5553A0AB9 for <quic@ietfa.amsl.com>; Wed, 15 Sep 2021 11:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 t5zpMUd7h99f for <quic@ietfa.amsl.com>; Wed, 15 Sep 2021 11:37:37 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 0964B3A0AB6 for <quic@ietf.org>; Wed, 15 Sep 2021 11:37:36 -0700 (PDT)
Received: from xse224.mail2web.com ([66.113.196.224] helo=xse.mail2web.com) by mx135.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mQZmj-000EGT-Ef for quic@ietf.org; Wed, 15 Sep 2021 20:37:32 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4H8pqC0BVRzLVB for <quic@ietf.org>; Wed, 15 Sep 2021 11:37:27 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mQZmg-0002wV-T0 for quic@ietf.org; Wed, 15 Sep 2021 11:37:26 -0700
Received: (qmail 15533 invoked from network); 15 Sep 2021 18:37:25 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.141]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 15 Sep 2021 18:37:25 -0000
To: Ian Swett <ianswett@google.com>
Cc: IETF QUIC WG <quic@ietf.org>
References: <163148817257.17060.13853059958631975884@ietfa.amsl.com> <5f7f77c4-45f3-126a-4fca-f4d564b6a19d@huitema.net> <CAKcm_gO5y=vJK+fNB1fL-pPi_6zTCfcSWWCp6NHbqgu4bZ5+bg@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: New Version Notification for draft-huitema-quic-mpath-option-01.txt
Message-ID: <8c2a3a84-fa1f-5d69-fa07-f91a65e81e0a@huitema.net>
Date: Wed, 15 Sep 2021 11:37:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CAKcm_gO5y=vJK+fNB1fL-pPi_6zTCfcSWWCp6NHbqgu4bZ5+bg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.224
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.06)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT90tBsp6aibtit3R9VpYf8QPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCGN9 22LRfpqX5tOXKqgkQwHmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaqlHdH9stIYSUOP2ajLGtTxQ6V51u76v35b1wNe/MvdL/hXir I7jpLA3NtNK1rbkD2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NlkBmbR1LS6Kx8w5MHqDEE6PzQQlKIV+L7fcVy/4+mAjp gifaS0+Isug8Z1fNhcpUDRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfPISAFZv5Ppuyu9ZXjexpGtUoFIvD3sIcP1fhJPM6B/8CSnK Bm4MQGTDObudyUfjfyZxm4fR8yOHA06pZKvCwY2J+dym1L8cD17Js0v4cp1MKS5Dc834sB0BEX7M SNzelTcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/MrFmzAh_oW34Ov9KvQZkYbscqeM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 15 Sep 2021 18:37:43 -0000

I am maintaining the draft using GitHub, 
https://github.com/huitema/quicmpath. You can certainly enter editorial 
issues there. You could start other discussions too, but it is probably 
preferable to have discussions of substance on the mailing list, because 
the draft has not been adopted by the WG yet, and the repo is not 
managed by the WG.

-- Christian Huitema

On 9/15/2021 6:19 AM, Ian Swett wrote:
> Thanks for writing this Christian, I have a new use case for which I think
> this simpler single-PN space version of multipath would be perfect.  The
> marginal implementation complexity on top of our existing connection
> migration implementation seems like it will be relatively small.
>
> Is there a github repo to create issues or editorial PRs, or should I leave
> any comments via email on the list?
>
> Thanks, Ian
>
> On Sun, Sep 12, 2021 at 7:20 PM Christian Huitema <huitema@huitema.net>
> wrote:
>
>> Following prompting by Michael Eriksson, I updated and resubmitted the
>> QUIC Multipath Negotiation Option draft, describing the "simple multipath
>> option". I cleaned up the draft in the following way:
>>
>> 1) Make it strictly about negotiating transmission on multiple paths
>> without otherwise changing the QUIC transport protocol. The new draft just
>> defines a transport parameter for negotiating the option, and does not
>> define any new frame type.
>>
>> 2) Allow the negotiation to optionally negotiate the path management and
>> scheduling extensions defined in draft-liu-multipath-quic, i.e., the
>> PATH_STATUS and QOE_CONTROL_SIGNALS. When that is negotiated, we obtain
>> pretty much the same behavior as draft-liu-multipath-quic, but using a
>> single number space instead of multiple number spaces.
>>
>> 3) Add a section with Implementation Considerations, based on the
>> experience in early tests (and the implementation in picoquic).
>>
>> -- Christian Huitema
>>
>>
>>
>>
>> -------- Forwarded Message --------
>> Subject: New Version Notification for
>> draft-huitema-quic-mpath-option-01.txt
>> Date: Sun, 12 Sep 2021 16:09:32 -0700
>> From: internet-drafts@ietf.org
>> To: Christian Huitema <huitema@huitema.net> <huitema@huitema.net>
>>
>>
>> A new version of I-D, draft-huitema-quic-mpath-option-01.txt
>> has been successfully submitted by Christian Huitema and posted to the
>> IETF repository.
>>
>> Name: draft-huitema-quic-mpath-option
>> Revision: 01
>> Title: QUIC Multipath Negotiation Option
>> Document date: 2021-09-12
>> Group: Individual Submission
>> Pages: 12
>> URL:
>> https://www.ietf.org/archive/id/draft-huitema-quic-mpath-option-01.txt
>> Status: https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-option
>> Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-mpath-option-01
>>
>> Abstract:
>> The initial version of QUIC provides support for path migration. We
>> propose a simple mechanism to support not just migration, but also
>> simultaneous usage of multiple paths. In its simplest form, this
>> mechanisms simply requires that multipath senders keep track of which
>> packet is sent on what path, and use that information to manage
>> congestion control and loss recovery. With that, clients can send
>> data on any validated path, and server on any validated path on which
>> the client recently sent non-probing packets. A more sophisticated
>> mechanism can be negotiated to explicitly manage paths and packet
>> scheduling.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>