Re: [quicwg/base-drafts] 5tuple routing (#3536)

Nick Banks <notifications@github.com> Mon, 30 March 2020 01:11 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 35FCE3A0522 for <quic-issues@ietfa.amsl.com>; Sun, 29 Mar 2020 18:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.082
X-Spam-Level:
X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.282, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 yqYoO2SPA1MV for <quic-issues@ietfa.amsl.com>; Sun, 29 Mar 2020 18:11:24 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C2C3A0486 for <quic-issues@ietf.org>; Sun, 29 Mar 2020 18:11:23 -0700 (PDT)
Received: from github-lowworker-d1d6e31.ash1-iad.github.net (github-lowworker-d1d6e31.ash1-iad.github.net [10.56.105.50]) by smtp.github.com (Postfix) with ESMTP id 0E5158C006D for <quic-issues@ietf.org>; Sun, 29 Mar 2020 18:11:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585530683; bh=Ksvd/Cu+SnYF/mXupJdKT6e1hI22RoHgLMXQWx5zsP0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AZx8Mleiidco2PwvBxXpYINb0lF8I8nqeowFjC3IIc5FKzSXy3/z6+FQ37M5CzuEA K1Ajqi0RG3RJfbGUeY6pkiamsijD8ujdk885lJHfV6z5rQd2XcZMFmBOpqxgDTvufm pWaShbpLlf78EWlf4/dyQAfU5z3gC7V8bpzJBzoc=
Date: Sun, 29 Mar 2020 18:11:22 -0700
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2VGPZQRRNTSU3ZQPN4RUUDVEVBNHHCFYX2PM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3536/c605733269@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3536@github.com>
References: <quicwg/base-drafts/pull/3536@github.com>
Subject: Re: [quicwg/base-drafts] 5tuple routing (#3536)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e81473af2340_5d2d3fe4538cd9681665ef"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/PZJvuiENnx_eZk1Qi2iIj0AVgOs>
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: Mon, 30 Mar 2020 01:11:25 -0000

> I don't think that the implied semantic is entirely accurate. In previous discussions, @nibanks pointed out that they would handle NAT rebinding with special logic (and likely move to close connections shortly afterwards). That suggests that keep-alive logic was not necessary for those connections that might be affected. However, this text suggests that if you see the transport parameter you would want to use keep-alives, or just do explicit closes within your understanding of the NAT timeout window to avoid the possibility of migration.
> 
> Thus, rather than a "please avoid X", this turns into a "take active steps to prevent X".

I'm actually fine with this. We were considering keep alives on the server side when we can't support migration (or NAT rebinding) based on the current infrastructure. So having the spec suggest keep alives to the client would be better. It would allow the client to choose if it would prefer keep alives or just to close the connection.

-- 
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/3536#issuecomment-605733269