Re: [AVTCORE] Reliable Stream Resets: Requesting a Reset at a Specific Offset

Kazuho Oku <kazuhooku@gmail.com> Fri, 13 October 2023 06:38 UTC

Return-Path: <kazuhooku@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 CF2C8C14CE53 for <quic@ietfa.amsl.com>; Thu, 12 Oct 2023 23:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7g46Tn6tq1e for <quic@ietfa.amsl.com>; Thu, 12 Oct 2023 23:38:59 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E794C14CEFA for <quic@ietf.org>; Thu, 12 Oct 2023 23:38:59 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-9b9ad5760b9so261747966b.3 for <quic@ietf.org>; Thu, 12 Oct 2023 23:38:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697179138; x=1697783938; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=m8BHaMhEIkjR88cL+f9xbxaywoeaG8BmUoQXButFkWE=; b=mbtom85BwOfGt/CXTVwDVySuHiljklXavLFLvbwfJnTzPjvQ8/q+wlMCz4C8Ob0rv3 IrNnXWH6xpYiZ5znlYiQf9/gxGTAgeiBvWTJmF6MCRzuOVy9rPJz+WbTMPho4oKv8oIM j1Q3Ycs6CDfcP+GKAmmY4OJKEElknRIl4WvN2vdCLrbE8pcQh5NNu8MbzNKW6fnbLWp5 d1sSFxMVMk2e/Pxmm9Z4lJul7B4GprzYiw0VbRvte1ALt8QUnINfNqqZLCgoS5O9xwwg 2bzOS/vx7iN9VJjWiOjcXyNr0+h3WuwNQp5RQf/mImTEzyAa5pHN+06lu8LWxqCjwKPR dF4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697179138; x=1697783938; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m8BHaMhEIkjR88cL+f9xbxaywoeaG8BmUoQXButFkWE=; b=POu2H6txULNR/X4Auryg5vPDUPRDGEgiJEgnIpyXnHxNEaTbKf+QeHzFYrm5mo2KD+ VjTPtsGZ27QsUmNNuQTdT1bXBoieH5hOIB1QeQ324EtQ2iGAKPMscoM2D0DaXtyu5RlQ UNnMBpARtPjYLM0HdHr6Hrvk71ivB5mj4nWjGGX+BveKEfSXKu3MqSLO1+9mKoxZo1Ad 1gJB4imrgVRPzaJBVGihvlSD68lfV5r956z/2hcRP/PyjfDPFBlwZLtrY562IS0Kf97v eABGBNt4ENfFMpT5ORofKsn5Vu4YWhLLH9CIJU9SX0vCtELA3ZRDdj42BIty7IcIqhAn yD+Q==
X-Gm-Message-State: AOJu0Ywxk/3QEzJ/vjRJeaYOON9PKcmPJSK7RloeWTax+wiBtRxZZBDE /baBXTlqB+U8kycsNlH52tKHI7YqreaHlpsegx4AoKn3
X-Google-Smtp-Source: AGHT+IF/py6lgqQ6qEBOmYF60eoOdyY5NpSL+Te544MRKATfBejFsuKUdVp8PNKFyNTPVzYh57eeiOxJxNKJ+Zm5gvs=
X-Received: by 2002:a17:907:9724:b0:9b2:a7db:9662 with SMTP id jg36-20020a170907972400b009b2a7db9662mr28646619ejc.12.1697179137690; Thu, 12 Oct 2023 23:38:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAOYVs2r9e5YnNW+pNrtB8UF-TFFKp5PvHV1ScfdcY40qAZ0atA@mail.gmail.com> <fe1d8341-d511-8b97-6943-e8a8e2a2f6e0@tum.de> <CAPDSy+7Rioi=vvx4kD8Ly=-adsqas8rDFdB+tcmMyUmVFsE_5A@mail.gmail.com> <0304a741-d79d-4ece-9dd7-223e3dba33a0@betaapp.fastmail.com> <CANatvzw0c-2zyb6BXPoL8BWxLtDDJX-SRqBs+60p2Zh6ASxu5Q@mail.gmail.com> <8e5026d2-f302-444e-90e5-25e031613b5f@betaapp.fastmail.com>
In-Reply-To: <8e5026d2-f302-444e-90e5-25e031613b5f@betaapp.fastmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 13 Oct 2023 15:38:46 +0900
Message-ID: <CANatvzyqJQssE_ibSxBzHNGuJrSOxDDCKB4axzBi=G9rbhf2=w@mail.gmail.com>
Subject: Re: [AVTCORE] Reliable Stream Resets: Requesting a Reset at a Specific Offset
To: Martin Thomson <mt@lowentropy.net>
Cc: quic@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009f50090607934fc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/IZmffspC0yiwzfsGcwmwseF_mpg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 13 Oct 2023 06:38:59 -0000

2023年10月13日(金) 9:18 Martin Thomson <mt@lowentropy.net>:

> On Fri, Oct 13, 2023, at 11:11, Kazuho Oku wrote:
> > 2023年10月11日(水) 10:07 Martin Thomson <mt@lowentropy.net>:
> >> I'm more concerned about adding another negotiation point for the
> request.  If they progress in parallel, then we need separate negotiation
> for each and that gets tricky when there is an interdependency like this.
> >
> > If that is the main concern, I think we might consider changing the
> > Transport Parameter used for negotiating Reliable Reset to take a
> > version number.
>
> I'm not enthusiastic about adding extra extension points like that.
>
> My sense is that either ENOUGH is worth doing or not, and that won't
> change much in future.  If the protocol needs to get much more complex in
> order to support it, then it will be less worthwhile.
>

Thanks, I think I'm fine with that too.

After all, it is not difficult to have something like ENOUGH inside the
application protocol, as such a signal can be sent on a control stream.
That's very different from CLOSE_STREAM, without which it is complicated to
guarantee partial delivery of stream data.

-- 
Kazuho Oku