IETF Logo Mail Archive

Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)

MikkelFJ <notifications@github.com> Sun, 23 June 2019 17:52 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 D81C012021C for <quic-issues@ietfa.amsl.com>; Sun, 23 Jun 2019 10:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.391
X-Spam-Level:
X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 LtdioX0cEpUZ for <quic-issues@ietfa.amsl.com>; Sun, 23 Jun 2019 10:52:58 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52CC1200E5 for <quic-issues@ietf.org>; Sun, 23 Jun 2019 10:52:57 -0700 (PDT)
Date: Sun, 23 Jun 2019 10:52:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1561312376; bh=ABBOgzKjo7xF4D66KRmbtACRSyyDEizqXv+pc+l8NZ8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=G6BjE3Tgd3k2iuCOheSNka7q924NRJmRm8MPcNg9PuifOGXDmEUibISXk4h6X8MBy wnn1p9hqdDdvmh8ijsSs3SetvAWLbXnNIW1kR+qwP0GlXCw1MvymHQ0zTsTMmo9F7B 4Xgl58yCuhtp3cGL5rt2zmvErE3oKd+0s/PoEOmE=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK25W6MVBTL734RSTIV3DTXPREVBNHHBWZGHNE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2834/504773171@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2834@github.com>
References: <quicwg/base-drafts/issues/2834@github.com>
Subject: Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d0fbc7895da0_42253fab2fccd96c10093ad"; 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/XncY-etAZAiHFSgNhtNUm09pFtw>
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: Sun, 23 Jun 2019 17:53:00 -0000

> The whole point here is that you want to route all long header packets to the same place. Why would you route the initial packets one place, and then handshake packets somewhere else? If you didn't like where they went in the first place, don't route them there.

The initially discovering LB can choose a random or least loaded endpoint to send the initial packet to. This endpoint decides a new CID it sends to the client. When client responds, the original LB sees a new CID in a LH, it knows that it is not a random OCID because it is no longer an initial packet. Therefore it routes the CID to the correct server assuming the LB understands the CID that the server generated.

If the client retransmits initial, it might land on another server, but that should work fine.

-- 
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/issues/2834#issuecomment-504773171

v2.23.0 | Report a Bug | By Email