IETF Logo Mail Archive

Re: [Masque] Zaheduzzaman Sarker's Yes on draft-ietf-masque-h3-datagram-10: (with COMMENT)

David Schinazi <dschinazi.ietf@gmail.com> Thu, 16 June 2022 16:36 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A1EC157B43; Thu, 16 Jun 2022 09:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4Om2wiyBsdf; Thu, 16 Jun 2022 09:35:57 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 36D66C14F718; Thu, 16 Jun 2022 09:35:57 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id gd1so1860060pjb.2; Thu, 16 Jun 2022 09:35:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IiZ2EApS0v7yCeD5dRYYSZa4BjwxTFaOb/G2Lv8lOPA=; b=Ml5AI2Uycbe4jzn1qnhXnbAEwE5FtiCu9lzasm7C7oHeNq5lJCH8W7H/r78xCbto67 YvWmnaZtU8ADpZRVqXWhLyZnzaR5d8CdgQH8yNK28z8w7DdPY0tNC7kNtUEvwhimrOVF FiauoWEHTYE61/qKTuT0DvgCqXO0MS1tlklQIo7VshHPbwAk6YcpqzDxV27Y58zTWRnK jzj2LIodegldMcM8hUjwweCCaJuqSllnPbQN7DTJ6XSp8GpNzgdcjVRWQLwLiLXqblrG +gXq4RCYWurjo08WzHKA9YYHuCjSfe4tiLe0+aaQoLb/mQfUnsLhr/iB8Dz9RQeRcHKu zNJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IiZ2EApS0v7yCeD5dRYYSZa4BjwxTFaOb/G2Lv8lOPA=; b=HGryxocPyQgdAf+jZWczKm3QQr+0cWmoQ7HJ33tysiTHUSxjUKgl6OD64ZzdLIpi0d bQR+f1AIIBwSXyvyR2HDjBjFWI/Lmp6xsSbwVK1BYEnnliedUEsiWtUv9NVtE8UiqKSp 2WOsl57glIBitzRr0UTaKc1ayoEkeRIHGLEXz9+Ey8CyKqRF0voodReKzuMjBLPpOjOu G+lCmcaAXz22WA5E5HGdeLzIJ9gADdOjCVN4u2KMPyfgshEMyAal/cQySBVc+hGWu+yz djjDhOqdJxgTpQZfcs8sTKIULuezqgC6MCPoI7NlPWHjJBEtEtRA3UXpGSYtL6sMQ9XV 2gLw==
X-Gm-Message-State: AJIora8ePAdadMntrLZ9ga1bhmotgd8PZJMXdVLZ/ejucj7NBTUUcix2 Vvss/m/Zg8vX6R1laBkqUU6eR1+VWC7FhfU9ilw=
X-Google-Smtp-Source: AGRyM1vtiXuYGrqllZ/PujMlV+t3950RCf1tU91nvmxkbhJglZdPJgnHdDMvf6jXuh6kjAx5HjFp8Tyd4AaAOMh4z1I=
X-Received: by 2002:a17:902:a58b:b0:168:b680:c769 with SMTP id az11-20020a170902a58b00b00168b680c769mr5733640plb.32.1655397356157; Thu, 16 Jun 2022 09:35:56 -0700 (PDT)
MIME-Version: 1.0
References: <165532474199.60753.8589453083068899777@ietfa.amsl.com> <CAPDSy+4k7B1mQL7cqZh2b2ES2U_CNENhaUkUqFrm77M1DAzUtg@mail.gmail.com> <D2F3DCB9-3598-4025-A7E6-0B952F8844E6@ericsson.com>
In-Reply-To: <D2F3DCB9-3598-4025-A7E6-0B952F8844E6@ericsson.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 16 Jun 2022 09:35:44 -0700
Message-ID: <CAPDSy+7tb1dUamY+MpQ6GwRRoX=w9FTS7jzExJPJTYYyV0N3fA@mail.gmail.com>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-masque-h3-datagram@ietf.org" <draft-ietf-masque-h3-datagram@ietf.org>, "masque-chairs@ietf.org" <masque-chairs@ietf.org>, MASQUE <masque@ietf.org>, Christopher Wood <caw@heapingbits.net>
Content-Type: multipart/alternative; boundary="000000000000603f0a05e1933bbd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/x3SJmc6E1cRiBP3wWHpLfh_FLpo>
Subject: Re: [Masque] Zaheduzzaman Sarker's Yes on draft-ietf-masque-h3-datagram-10: (with COMMENT)
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2022 16:36:01 -0000

Hi Zahed,

I'm confused. “treat as an HTTP/3 connection error of type
H3_DATAGRAM_ERROR (0x33)” is very clearly defined in QUIC and HTTP/3 - it's
a connection error, not a stream error. Additionally, there is no stream
involved at the stage of the processing path that leads to this error, so
it is not possible for an implementer to do it wrong. Am I missing
something?

David

On Thu, Jun 16, 2022 at 2:27 AM Zaheduzzaman Sarker <
zaheduzzaman.sarker@ericsson.com> wrote:

> Thanks for addressing my comments.
>
> One reflection inline.
>
> //Zahed
>
> On 16 Jun 2022, at 02:02, David Schinazi <dschinazi.ietf@gmail.com> wrote:
>
> Thanks for your comments, Zahed!
> Responses inline.
> David
>
> On Wed, Jun 15, 2022 at 1:25 PM Zaheduzzaman Sarker via Datatracker <
> noreply@ietf.org> wrote:
>
>> - Section 2 : should it be HTTP/1.x instead of HTTP/1 :-)?
>>
>
> Agreed, fixed in this commit:
>
> https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/commit/e9922855baf774abed3612dc26bcb22145e1ad9f
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-1a8332a43397eb6d&q=1&e=6c7a336f-be95-4a3e-bfb3-ab5aae69ee31&u=https%3A%2F%2Fgithub.com%2Fietf-wg-masque%2Fdraft-ietf-masque-h3-datagram%2Fcommit%2Fe9922855baf774abed3612dc26bcb22145e1ad9f>
>
>
>> - Section 2 : it says
>>
>>            "value MUST be treated as an HTTP/3 connection error of type
>>            H3_DATAGRAM_ERROR (0x33)"
>>
>>      does this mean request stream MUST be aborted as it was also written
>> in
>>      the section?
>>
>
> The text you're referring to discusses what to do when Quarter Stream ID
> >= 2^60.
> When that happens, multiplying the Quarter Stream ID by four would result
> in an
> invalid stream ID, so it is impossible to abort that stream. That's why we
> close the
> entire connection.
>
> Right, that is the behaviour we want. However, it is not obvious if we
> just state “ treat as an HTTP/3 connection error of type H3_DATAGRAM_ERROR
> (0x33)” as it seems H3_DATAGRAM_ERROR can result in both stream termination
> and connection termination. I think we should be explicit about terminating
> the connection or refer to section 8 of RFC9114 for definition of
> "connection error".
>
>
> - Section 3 in general : I think we can be specific that "intermediaries"
>> are
>> HTTP intermediaries as defined in HTTP semantic , as it is done in the
>> draft-masque-connect-udp?
>>
>
> Agreed, fixed in this commit:
>
> https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/commit/7328c4fdc84aedd6a69ebfd0fe2df711cad571e7
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-4c3b00f8a1770c3f&q=1&e=6c7a336f-be95-4a3e-bfb3-ab5aae69ee31&u=https%3A%2F%2Fgithub.com%2Fietf-wg-masque%2Fdraft-ietf-masque-h3-datagram%2Fcommit%2F7328c4fdc84aedd6a69ebfd0fe2df711cad571e7>
>
>
>
>

v2.23.0 | Report a Bug | By Email