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

MikkelFJ <notifications@github.com> Tue, 05 February 2019 07:50 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 1C4FA130E13 for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 23:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 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] 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 Kt_viRxWw3bw for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 23:50:20 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17CE130DEC for <quic-issues@ietf.org>; Mon, 4 Feb 2019 23:50:19 -0800 (PST)
Date: Mon, 04 Feb 2019 23:50:18 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549353018; bh=491gxVJfh7yVm5ZiKLTVWLyANAfX88Keho2WTwT1nUQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HIh+fo/AlEnU0bkPr1i8OsHXfpJIgqFzIu41Hftb8phin4ZSlvTwVkja1W33GJsjD f6oGCAg2vBDWLpFXhmYOLwNaW7ue6d9xoUcLO9JU5IWxKWiOQtlJZ/1Jjmi3jvnM26 29qy3kBRL4KKmUuiTacSzgd4ykAaZwwL+JJtxCuk=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba43d617a754cf01940415de28b1480407e5598a192cf000000011871023a92a169ce1833165d@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/c460543273@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_5c59403a7529a_327f3fc3fd0d45c05520af"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/XtvE-8ETwmGu3gMxm7M1YaaY2Wc>
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:50:23 -0000

> 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?

To an extend yes, but if you do care about performance, it can be a simplification: You need the core functionality regardless, so it is mostly function calls to logic that must exist either way. And, it allows you to be more lazy performance wise when dealing with the complexities of the handshake where crypto overhead and low packet count does not make optimisations worthwhile. This means you can shift that focus to short packets.

This gets into biblical citations, but ...

>Every QUIC packet that is coalesced into a single UDP datagram is separate and complete.

but it also says that you cannot have multiple connections, and you cannot have long headers post 1-RTT. 

Technically you can coalesce a packet "sent" before the packet being coalesced, but if you have seen a short header, you can reasonably assume that any long headers are of no interest and therefore drop processing of that datagram ASAP.

-- 
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-460543273