IETF Logo Mail Archive

Re: Split error codes in two

Martin Thomson <martin.thomson@gmail.com> Tue, 05 September 2017 11:18 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68913292F for <quic@ietfa.amsl.com>; Tue, 5 Sep 2017 04:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ds9TnIUzXRU7 for <quic@ietfa.amsl.com>; Tue, 5 Sep 2017 04:18:54 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1C113292B for <quic@ietf.org>; Tue, 5 Sep 2017 04:18:54 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id n18so22360291oig.2 for <quic@ietf.org>; Tue, 05 Sep 2017 04:18:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D2I/8yprzdnUOnoDJXQQ1v3uMZHocBfOAJ0Vygq078M=; b=uZSNq3uSivpz1i5i5v4ECrHQs4eRMwMA/AheBDJblyM5acWQ33lsK/pBVYMvbtBtqy TEqmtft0vSxeYfkKNxXM/FjIgJAWapB6woWKAewXZ7EHGCYWGcV26FD+dkYQlT/Oj4aF qTSUSVMEbUadCr6CaYucJfHHQgomgAcwu3lppq+g/36DqiKRUnuIYXzyzl/CrPBKQsdH pw0LfXrfdaF3CgSbjdtTl+3N4bZlnXZlSo/rsNqc2WU5KWfE84jsRZoubBnH9GFHSXso bJqeYvJ+fOwbgJyGQySoW1BbdJsasvdb2rWisg1cCCK4UmmTcICbgRvkCrIsPMsCdUV/ DkTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D2I/8yprzdnUOnoDJXQQ1v3uMZHocBfOAJ0Vygq078M=; b=l3pr5hEYSDkyyoqcBRfUWTHBF1vZBjQjVOdDkRDpHLCI2OYzgXnQpsiLzXlYMTVQpO iTkLmL9kXn7E3ls0U/IILtiEj49X8CrbsHDNvQu94HgnVIOUp9IfqtKE0F8D7DpPt4ye ng44tj8wOAz8097zNDvDvZNXBleaEYU/zG0VAZn410yct2Lfs2l61LCSnK+riWoVlzR1 Cy+1UCeAVrVQE/UFPFkeOpiR7ZLMvRC3IMcH1DEyRMAPj90YMbUNqUaK+ZOtsvLn95am xZLZx43GTANYcBkQqV/gcyY0E4JkBzhUhnwvC0ZhZ8KJnnF6obP86tUUZ7bCv9TWa47E H9uA==
X-Gm-Message-State: AHPjjUgiDsg1GM17UgrARjGQ0AwW9SEUMn2RaTgxlufy9koS9HF0KYI4 KMVs1Z9jesgUAtCYU8poQmJv69rOqA==
X-Google-Smtp-Source: ADKCNb4TYtT+kDaQEGPIIgJZeK7ypkQrkWDLCoFObH3PvY//2xQKgRAKaDYiJ0w+HdZN867xJSBjH0+HPnoEVJC3g+s=
X-Received: by 10.202.229.203 with SMTP id c194mr3551010oih.92.1504610333448; Tue, 05 Sep 2017 04:18:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.14.77 with HTTP; Tue, 5 Sep 2017 04:18:53 -0700 (PDT)
In-Reply-To: <CAAZdMafBWFWtC7A60P1CMm_6nUnbW+_Tx_7re1bAo7Vx2kLdcA@mail.gmail.com>
References: <CABkgnnWwGAyHzkST9o9ueVmBw3_TpJun=dv2X+HL2snXSZJgew@mail.gmail.com> <CAAZdMafBWFWtC7A60P1CMm_6nUnbW+_Tx_7re1bAo7Vx2kLdcA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 05 Sep 2017 21:18:53 +1000
Message-ID: <CABkgnnWphw3k=f3==2y3AhexQCj9Py50SLSEH06nN3MN0SCerQ@mail.gmail.com>
Subject: Re: Split error codes in two
To: Victor Vasiliev <vasilvv@google.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/YzIcgJIKV_5-Vv6V9-mRk-17jzc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Sep 2017 11:18:55 -0000

On Tue, Sep 5, 2017 at 8:12 PM, Victor Vasiliev <vasilvv@google.com> wrote:
> On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> The basic idea here - one that I believe that we have agreement on,
>> but would like to confirm - is that only applications should be
>> cancelling streams.  In short: if the transport kills a stream that
>> the application was relying on, the whole application protocol state
>> becomes indeterminate.
>
>
> I assume this means only on the wire?  Because you have to close
> the streams both when your connection goes down, and when you get
> a 0-RTT reject.

I forget where this discussion happened, but the current thinking was
that 0-RTT reject doesn't result in streams being closed.  Instead, it
causes any data that was sent to need to be retransmitted.  Basically,
treat it as lost (though not for the purposes of congestion signals,
waves hands a little).  Does that make sense?

v2.23.0 | Report a Bug | By Email