Re: [quicwg/base-drafts] Describe PMTU probing that includes source connection ID for routing … (#2402)

Kazuho Oku <notifications@github.com> Tue, 05 February 2019 07:26 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE939130DEC for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 23:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.552
X-Spam-Level:
X-Spam-Status: No, score=-12.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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=github.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 yQ6Fvl-OhRWV for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 23:26:11 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653A6130E09 for <quic-issues@ietf.org>; Mon, 4 Feb 2019 23:26:11 -0800 (PST)
Date: Mon, 04 Feb 2019 23:26:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549351570; bh=MAKoGtxTlB+t1LUpwjabrbFwElYS+SPEww1BYhOwE6s=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tAjE27gpV0jKJXfGsCwj+G7q6uUZdDY2h70RELQfBrpwKfI60OQjxhyZYELItkBut 5CCnllLe5RjlLRrOBflE5CWKxXWfyZLyC5Y9S9McFA9If0meMUXZO1IHzaDmfmWh40 Yy2xnkyWjs2c2Fosh6xam2U91zCFqtzy54IBc9f0=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abfeb133c338432e19fa2198f860b697ef9c15d90992cf000000011870fc9292a169ce1833165d@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2402/c460538290@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2402@github.com>
References: <quicwg/base-drafts/pull/2402@github.com>
Subject: =?UTF-8?Q?Re:_[quicwg/base-drafts]_Describe_PMTU_probing_that?= =?UTF-8?Q?_includes_source_connection_ID_for_routing_=E2=80=A6_=28#2402=29?=
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c593a924e818_5b453febd22d45bc443674"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/IiXH7vwwNT8CgY2QvLLQJAn8Dp0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2019 07:26:14 -0000

@mikkelfj 
> The entire idea about not having long headers post 1-RTT, and to make a note of it, is to allow implementations to focus on short packets only for the reminder of the connection, and dropping all context about separate number spaces etc.. If that stops being the case, all the bootrapping mess comes back to haunt you.
> 
> I'd switch to different packet processor post handshake so there is no ACK special handling etc.

The design does not require the receiver to actually handle the long header packet. Simply dropping it is fine, as long as the receiver processes the short header packet that is being coalesced with the long header packet.

I understand the fact that you want to have an optimized path for short header packets. That's fine.

OTOH, the receiver needs to handle a coalesced datagram that carries various types of long header packets and a 1-RTT packet, at least during the handshake. This is true even if you do not have a corresponding key (e.g. you need to "drop" a 0-RTT packet in a coalesced datagram even when you do not not have the 0-RTT key). 

Considering that, I am not sure if it a good idea to disable the logic to split coalesced datagram into multiple packets when dropping the Handshake key. Isn't it an additional complexity to disable the logic upon the completion of the handshake?

FWIW, the specification currently states: _Every QUIC packet that is coalesced into a single UDP datagram is separate and complete. Though the values of some fields in the packet header might be redundant, no fields are omitted. The receiver of coalesced QUIC packets MUST individually process each QUIC packet and separately acknowledge them, as if they were received as the payload of different UDP datagrams. For example, if decryption fails (because the keys are not available or any other reason), the the receiver MAY either discard or buffer the packet for later processing and MUST attempt to process the remaining packets._ ((section 12.2)[https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.12.2}]).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460538290