IETF Logo Mail Archive

Re: [Webtransport] Draining WebTransport connections

Victor Vasiliev <vasilvv@google.com> Thu, 03 November 2022 21:48 UTC

Return-Path: <vasilvv@google.com>
X-Original-To: webtransport@ietfa.amsl.com
Delivered-To: webtransport@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6572C1524B6 for <webtransport@ietfa.amsl.com>; Thu, 3 Nov 2022 14:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.607
X-Spam-Level:
X-Spam-Status: No, score=-17.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8E5S2XoTB_3s for <webtransport@ietfa.amsl.com>; Thu, 3 Nov 2022 14:48:38 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 EDEEDC14F722 for <webtransport@ietf.org>; Thu, 3 Nov 2022 14:48:38 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id d24so3186893pls.4 for <webtransport@ietf.org>; Thu, 03 Nov 2022 14:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=n/MLd4U6GHz+rF4o3oSv81t7mmi9JcrddE3MLSOG0qI=; b=fpjxiixfClH62CA+T3MT+/+sCaDZTiJ8a0aouzzWGonnnmfrdEvjCsjtA3fqQwUPth C/sLswYTVoEeP38TFIUAEYNrOpxBJZkKjqXMXTJ8SaqLIkn824q7Gbv+/CTJ42TPASQV l/c9pM1H9h90U2w0YGSagIQITo1Lcfk8KA/zHKKak9RqZQ0f9KhCwUAU/JzhRwLqJETL LrDGu6Z6mtDdvxnjzPmq3VjAbO9zDpJQc2siYIn24mRHP+T0g/Om3dK1w9B9gJcPQjw4 6rxS/9ELwP5giSD7SWdycQ8DQdXWyNl4FNL42EcBt4LxpYV5pAxVQNwBGRMIHo5pboao d8pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=n/MLd4U6GHz+rF4o3oSv81t7mmi9JcrddE3MLSOG0qI=; b=igz/N/hrRm+oZdXE/0fhIrPujWgIYIBmsxpiC0oRy9B4egC8HRn/Df217AZvJn/Yap ON7/Zm8caF9hEQykXAE1lAemB5PyQzlVR+D7Ip5iGdSvoIUsv6PxNi1qpd2OomWDIFX3 z9Gvy+mnnSBxqXtDtNthzHii67YbxWAQjxjcfWKfTXXxygpF5sSR8Luj2GJNuUN3mgdj wppCYJt04P8GqLjaLs8l9BNAqjsUpSNZZDAD758hW3Ib5n/78jtlDMwzb3j0Qz+UBwYX T1QxCWKfxj4N2ggz3tGmpqnqzct1L5n0ii86pc3O8oCGKRQnWodlR5s7mEoj6G1zZLlv We/A==
X-Gm-Message-State: ACrzQf3N3xJANByqEODWPFpVW21Tj3hq+gs6bowU2mfiSI3lIHKDxQbb hiZ69fh1S9w24UsSFexcMPpS6i8lrnKK740XFf7o+8JxlIDNfg==
X-Google-Smtp-Source: AMsMyM6qtqqQocaTx54xYd+RiiFcg62kDP9DImJpOwXiUxuZnqji+aqF2X0Knccou3xvtJQtjGdKzuWPO8zzY3uABdw=
X-Received: by 2002:a17:902:f60a:b0:186:5d06:8da4 with SMTP id n10-20020a170902f60a00b001865d068da4mr33295626plg.106.1667512117858; Thu, 03 Nov 2022 14:48:37 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obnjZvsfG_c9E+inFhBzb_6wpFBk1xuRt0eFEWJTgbm8Q@mail.gmail.com>
In-Reply-To: <CALGR9obnjZvsfG_c9E+inFhBzb_6wpFBk1xuRt0eFEWJTgbm8Q@mail.gmail.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Thu, 03 Nov 2022 17:48:26 -0400
Message-ID: <CAAZdMaftc+isyPPYzuaTkyF6HYiQ9sGs1tnrRmxfqf5pEKu66Q@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: WebTransport <webtransport@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000723ba805ec97ebf3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/gDKXq6wGNA2QE9LVuDEq1kKM1jw>
Subject: Re: [Webtransport] Draining WebTransport connections
X-BeenThere: webtransport@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: WebTransport WG <webtransport.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webtransport>, <mailto:webtransport-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webtransport/>
List-Post: <mailto:webtransport@ietf.org>
List-Help: <mailto:webtransport-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webtransport>, <mailto:webtransport-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2022 21:48:42 -0000

Hi Lucas,

There is a pull request pending to add those: <
https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pull/79>
I intend to put it on the slides for the next week's meeting.

Thanks,
  Victor.

On Thu, Nov 3, 2022 at 5:23 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hi WebTranport enthusiasts,
>
> I might have missed it but it seems that WebTranport doesn't have a
> capability to drain connections, similar to how GOAWAY works for H2 or H3.
> The crux of draining here is being able to tell a peer that creating new
> streams is no longer wanted (and possibly that they should move to a new
> connection to do that).
>
> draft-ietf-webtrans-http3-03 Section 4.6 [1] does say something but I
> don't think it helps:
>
> > HTTP/3 defines a graceful shutdown mechanism (Section 5.2 of [HTTP3
> <https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-03.html#HTTP3>])
> that allows a peer to send a GOAWAY frame indicating that it will no longer
> accept any new incoming requests or pushes. This mechanism applies to the
> CONNECT requests for new WebTransport sessions. A GOAWAY frame does not
> affect data streams for existing WebTransport sessions; those can continue
> to be opened even after the GOAWAY frame has been sent or received.
>
> The text is clear that H3's GOAWAY won't stop the peer creating new
> WebTransport streams. Absent explicit draining notification for
> WebTransport streams, the outcome seems to be to either expect spontaneous
> connection termination, or delegate it to applications on top of
> WebTransport to make their own solution up. Maybe we should just solve it
> in the WebTransport protocol, so that the WebTransport API factors it in?
>
> Cheers,
> Lucas
>
> [1] -
> https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-03.html#section-4.6
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>

v2.23.0 | Report a Bug | By Email