Return-Path: 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 D45F312017C for ; Tue, 16 Jul 2019 00:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 i0tbaNyMmKD9 for ; Tue, 16 Jul 2019 00:49:02 -0700 (PDT) Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24141200B6 for ; Tue, 16 Jul 2019 00:49:01 -0700 (PDT) Date: Tue, 16 Jul 2019 00:49:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1563263340; bh=XhPmRLlzJNDizAP8+UEHUToKZGacBNClRqkC87YSSi4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w/az84dSpmE8AdAH064fDRBkqn15pkT1BvF8iF2iS0fXVsPRub57o3+pCplRE1Uga SaWkDj3NT3GEpyQRkJ/y9b5EQUpJEB3kvDlU/baulH7QJ5kV16AV01XEvsv1iOA6sm OEHXcaVJMVXyvB7d6KNOs9jUmM5h2zObVIFFpMc4= From: MikkelFJ Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Small clarification in 12.2 Coalescing Packets (#2900) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5d2d816cbcfd4_35453fbe0dccd96c2842a4"; 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: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 07:49:04 -0000 ----==_mimepart_5d2d816cbcfd4_35453fbe0dccd96c2842a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The Path Probe is abusing coalescing to ensure to get a long header=0D reflected via an invalid old handshake packet.=0D =0D While I do not appreciate this design, everyone else seems to think it is= a=0D great way to solve that problem.=0D =0D If the old packet cannot not be skipped, this would not work. If the leng= th=0D cannot be decoded due to other changes, this design needs to be revisited= .=0D =0D More likely though, the packet can be skipped, but some implementations=0D= won=E2=80=99t, so path probing will be broken anyway.=0D =0D =0D On 16 July 2019 at 03.53.16, Nick Banks (notifications@github.com) wrote:= =0D =0D I went back and double checked. I thought Length followed the packet=0D number, which is variable length, but it does seem to precede the field.=0D= Perhaps all that does need to be done is to remove that sentence then.=0D= =0D =E2=80=94=0D You are receiving this because you are subscribed to this thread.=0D Reply to this email directly, view it on GitHub=0D ,=0D or mute the thread=0D =0D .=0D =0D =0D -- =0D You are receiving this because you are subscribed to this thread.=0D Reply to this email directly or view it on GitHub:=0D https://github.com/quicwg/base-drafts/issues/2900#issuecomment-511706288= ----==_mimepart_5d2d816cbcfd4_35453fbe0dccd96c2842a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The Path Probe is abusing coalescing to ensure to get a long header
=0D= reflected via an invalid old handshake packet.
=0D
=0D While I do not appreciate this design, everyone else seems to think it is= a
=0D great way to solve that problem.
=0D
=0D If the old packet cannot not be skipped, this would not work. If the leng= th
=0D cannot be decoded due to other changes, this design needs to be revisited= .
=0D
=0D More likely though, the packet can be skipped, but some implementations=0D won=E2=80=99t, so path probing will be broken anyway.
=0D
=0D
=0D On 16 July 2019 at 03.53.16, Nick Banks (notifications@github.com) wrote:=
=0D
=0D I went back and double checked. I thought Length followed the packet
=0D= number, which is variable length, but it does seem to precede the field.<= br>=0D Perhaps all that does need to be done is to remove that sentence then.=0D
=0D =E2=80=94
=0D You are receiving this because you are subscribed to this thread.
=0D Reply to this email directly, view it on GitHub
=0D <https://github.com/quicwg/base-drafts/issues/2900?email_source=3Dnoti= fications&email_token=3DAABPGN3Q7TB7653HEXMGXS3P7USYXA5CNFSM4ID3FA42Y= Y3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ7OL5I#issuec= omment-511632885>,
=0D or mute the thread
=0D <https://github.com/notifications/unsubscribe-auth/AABPGN2TD6NXLLDY6ET= GV5DP7USYXANCNFSM4ID3FA4Q>
=0D .
=0D =0D =0D

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on= GitHub, or mute the thread.

=0D = ----==_mimepart_5d2d816cbcfd4_35453fbe0dccd96c2842a4--