Re: [quicwg/base-drafts] Stateless Reset from clients, bis (#1505)

hardie <notifications@github.com> Fri, 29 June 2018 22:22 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 040A9130E29 for <quic-issues@ietfa.amsl.com>; Fri, 29 Jun 2018 15:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 DwBST5vWoc5F for <quic-issues@ietfa.amsl.com>; Fri, 29 Jun 2018 15:22:17 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90C9130E5E for <quic-issues@ietf.org>; Fri, 29 Jun 2018 15:22:17 -0700 (PDT)
Date: Fri, 29 Jun 2018 15:22:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1530310937; bh=ZihrpXXNCNnNEdO5yiBt2Vjs1hplwOgA1OLslpzOvJo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VjjmNQMJbW0QE7MI7FtBbQ0sAL8bPqdcP663qBJRkYt4TSeIpTszBUn2jws4iBaW3 Zs/gD0b6hYEYj4kYFKD3gDG25rWTi3qQdm3XPkKJBNcka2FLgXY+Y4LhUPaO2rwKXd jhGT4KFLuyYb+5rD1xKXqxVyE6Cl8AbJJIUzTd64=
From: hardie <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abfdcb133ccac84c671d1ed8c4268e7b2b8f4c532992cf00000001174e731992a169ce1418889d@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1505/401488385@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1505@github.com>
References: <quicwg/base-drafts/issues/1505@github.com>
Subject: Re: [quicwg/base-drafts] Stateless Reset from clients, bis (#1505)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b36b119ac8a_2a72b0640dd2f541275dc"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: hardie
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/emAhnoJ8sqFRcW54mnP-sQln6pk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 29 Jun 2018 22:22:20 -0000

Hi Igor,

I think I'm a little confused.  Some questions in-line.


On Fri, Jun 29, 2018 at 3:12 PM, Igor Lubashev <notifications@github.com>
wrote:

> In #466 <https://github.com/quicwg/base-drafts/issues/466>, we left it as
> the client cannot use Stateless Reset, until the server starts to use to a
> CID provided by the client's NEW_CONNECTION_ID. (Something that is actually
> not stated explicitly in the draft.)
>
> This is certainly not great, hence this issue.
>
> To fix this, I can think of a few alternatives:
>
>    1. A new frame that provides the initial Stateless Reset Token from
>    the client. It only applies to the initial CID (important to note, since
>    you do not want it to override the token from a subsequent
>    NEW_CONNECTION_ID in case of reordering).
>
> If the purpose of Stateless Reset is to abruptly tear down a connection,
I'm not sure what the re-ordering issue is.  Sending a Stateless Reset and
then sending more traffic on that connection seems odd.  Similarly, if the
client needs to know whether data already sent has been received, it seems
like it either has to wait until that data is acknowledged and/or use a
graceful shutdown.  I don't seen how a reset matches this--what am I
missing?


>
>    1. If NEW_CONNECTION_ID frame is received from the client with Seq=0
>    and Length=0, it provides the initial Stateless Reset Token (and is
>    considered to be Seq=-1, so the next NEW_CONNECTION_ID would actually be
>    Seq=0). I do not love this and would prefer just a new frame.
>
> —
>
I agree that this is not very lovable.

Ted


> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1505>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5BUeQGYOCQ9iZVNLKtp0Y_w-WFZNks5uBqZZgaJpZM4U9sIC>
> .
>


-- 
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/1505#issuecomment-401488385