Subject: [Webtransport] Error codes for closing WebTransport session

From: Victor Vasiliev <[email-masked]>
Date: Tue, 24 Aug 2021 04:52:29 -0400

In https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pull/60,
we have a proposal to add a mechanism that would let WebTransport
endpoints signal a reason for closing the session.  It's similar to QUIC
CONNECTION_CLOSE frame, in that it has both an error code and an error
string.

The question I want to ask (bikeshed) here is, what size should the error
codes be?

   - 62 bits should be reasonable, given that's what QUIC uses ~by default
   for all integers. However, it's not Web-friendly, since the Web platform
   has fairly poor support for integers larger than 53 bits
   (see MAX_SAFE_INTEGER).
   - 53 bits would work, but is somewhat awkward to deal with in native
   APIs.
   - 32 bits works well from all perspectives, but may be too small.

Do people have any strong opinions about the options above?

  -- Victor.

---

From: Yutaka Hirano <[email-masked]>
Date: Tue, 24 Aug 2021 19:03:37 +0900

As a web browser implementer, I'd like to avoid 62 bits from the reason
Victor described.

On Tue, Aug 24, 2021 at 5:52 PM Victor Vasiliev <vasilvv=
[email-masked]> wrote:

>    - 62 bits should be reasonable, given that's what QUIC uses ~by
>    default for all integers. However, it's not Web-friendly, since the Web
>    platform has fairly poor support for integers larger than 53 bits
>    (see MAX_SAFE_INTEGER).
> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 24 Aug 2021 19:43:23 +0000

As an OS implementor, I'd like to avoid the 53-bit proposal for the predicable reasons.

We have not seen issues with 32-bit error code space in our products. Do we have scenarios / projections / use cases that would suggest 32 bits would not be sufficient?

Thanks,
Tommy

From: Webtransport <[email-masked]> On Behalf Of Yutaka Hirano
Sent: Tuesday, August 24, 2021 3:04 AM
To: Victor Vasiliev <vasilvv=[email-masked]>
Cc: WebTransport <[email-masked]>
Subject: [EXTERNAL] Re: [Webtransport] Error codes for closing WebTransport session

You don't often get email from yhirano=[email-masked]<mailto:yhirano=[email-masked]>. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
As a web browser implementer, I'd like to avoid 62 bits from the reason Victor described.

On Tue, Aug 24, 2021 at 5:52 PM Victor Vasiliev <vasilvv=[email-masked]<mailto:[email-masked]>> wrote:
In https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pull/60<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-wg-webtrans%2Fdraft-ietf-webtrans-http3%2Fpull%2F60&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca0fbde2d15ed40ff92c408d966e689e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637653963094939183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GwdfwZFzCsf0Q9kIbDve5yBB8LUHCc6%2FlCAqo0ss01o%3D&reserved=0>, we have a proposal to add a mechanism that would let WebTransport endpoints signal a reason for closing the session.  It's similar to QUIC CONNECTION_CLOSE frame, in that it has both an error code and an error string.

The question I want to ask (bikeshed) here is, what size should the error codes be?

  *   62 bits should be reasonable, given that's what QUIC uses ~by default for all integers. However, it's not Web-friendly, since the Web platform has fairly poor support for integers larger than 53 bits (see MAX_SAFE_INTEGER).
  *   53 bits would work, but is somewhat awkward to deal with in native APIs.
  *   32 bits works well from all perspectives, but may be too small.
Do people have any strong opinions about the options above?

  -- Victor.
--
Webtransport mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webtransport<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fwebtransport&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca0fbde2d15ed40ff92c408d966e689e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637653963094949139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=2kMY8EohrOS%2Fk%2FkaM2l6LJsS1rAUbDiFRkDT0Js8h%2Bw%3D&reserved=0>

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 31 Aug 2021 15:24:41 -0400

It sounds like 32 bits should be just fine here; I'll update the PR then,
unless anyone objects.

On Tue, Aug 24, 2021 at 3:43 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> As an OS implementor, I’d like to avoid the 53-bit proposal for the
> predicable reasons.
>
>
>
> We have not seen issues with 32-bit error code space in our products. Do
> we have scenarios / projections / use cases that would suggest 32 bits
> would not be sufficient?
>
>
>
> Thanks,
>
> Tommy
>
>
>
> *From:* Webtransport <[email-masked]> * On Behalf Of *Yutaka
> Hirano
> *Sent:* Tuesday, August 24, 2021 3:04 AM
> *To:* Victor Vasiliev <vasilvv=[email-masked]>
> *Cc:* WebTransport <[email-masked]>
> *Subject:* [EXTERNAL] Re: [Webtransport] Error codes for closing
> WebTransport session
>
>
>
> You don't often get email from yhirano=[email-masked]. Learn
> why this is important <http://aka.ms/LearnAboutSenderIdentification>
>
> In https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/pull/60
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-wg-webtrans%2Fdraft-ietf-webtrans-http3%2Fpull%2F60&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca0fbde2d15ed40ff92c408d966e689e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637653963094939183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GwdfwZFzCsf0Q9kIbDve5yBB8LUHCc6%2FlCAqo0ss01o%3D&reserved=0>,
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fwebtransport&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca0fbde2d15ed40ff92c408d966e689e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637653963094949139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=2kMY8EohrOS%2Fk%2FkaM2l6LJsS1rAUbDiFRkDT0Js8h%2Bw%3D&reserved=0>
>
> --