1 of 37

WEBTRANS WG

IETF 116

Hybrid Meeting

Wednesday, March 29, 2023

04:00 - 06:00 UTC

00:00 - 02:00 Eastern Time

Session II, G314-G315

​

1

Mailing list: webtransport@ietf.org

MeetEcho: https://meetecho.ietf.org/conference/?group=webtrans

Notes: https://notes.ietf.org/notes-ietf-116-webtrans

2 of 37

IETF 116 Meeting Tips

In-person participants

  • Make sure to sign into the session using the Meetecho (usually the “Meetecho lite” client) from the Datatracker agenda
  • Use Meetecho to join the mic queue
  • Keep audio and video off if not using the onsite version
  • Wear masks unless actively speaking at the microphone.

Remote participants

  • Make sure your audio and video are off unless you are chairing or presenting during a session
  • Use of a headset is strongly recommended

2

This session is being recorded

3 of 37

IETF 116 Remote Meeting Tips

​

  • Enter the queue with , leave with

​

  • When you are called on, you need to enable your audio to be heard.�
  • Audio is enabled by unmuting and disabled by muting

​

  • Video can also be enabled, but it is separate from audio.
  • Video is encouraged to help comprehension but not required.

3

This session is being recorded

4 of 37

Resources for IETF 116 Yokahama

  • Information about IETF 116

https://www.ietf.org/how/meetings/116

4

5 of 37

Note well

This is a reminder of IETF policies in effect on various topics such as patents or code of conduct. It is only meant to point you in the right direction. Exceptions may apply. The IETF's patent policy and the definition of an IETF "contribution" and "participation" are set forth in BCP 79; please read it carefully.

As a reminder:

  • By participating in the IETF, you agree to follow IETF processes and policies.
  • If you are aware that any IETF contribution is covered by patents or patent applications that are owned or controlled by you or your sponsor, you must disclose that fact, or not participate in the discussion.
  • As a participant in or attendee to any IETF activity you acknowledge that written, audio, video, and photographic records of meetings may be made public.
  • Personal information that you provide to IETF will be handled in accordance with the IETF Privacy Statement.
  • As a participant or attendee, you agree to work respectfully with other participants; please contact the ombudsteam (https://www.ietf.org/contact/ombudsteam/) if you have questions or concerns about this.

�Definitive information is in the documents listed below and other IETF BCPs. For advice, please talk to WG chairs or ADs:

5

5

6 of 37

Note really well

  • IETF meetings, virtual meetings, and mailing lists are intended for professional collaboration and networking, as defined in the IETF Guidelines for Conduct (RFC 7154), the IETF Anti-Harassment Policy, and the IETF Anti-Harassment Procedures (RFC 7776). If you have any concerns about observed behavior, please talk to the Ombudsteam, who are available if you need to confidentially raise concerns about harassment or other conduct in the IETF.
  • The IETF strives to create and maintain an environment in which people of many different backgrounds are treated with dignity, decency, and respect. Those who participate in the IETF are expected to behave according to professional standards and demonstrate appropriate workplace behavior.
  • IETF participants must not engage in harassment while at IETF meetings, virtual meetings, social events, or on mailing lists. Harassment is unwelcome hostile or intimidating behavior -- in particular, speech or behavior that is aggressive or intimidates.
  • If you believe you have been harassed, notice that someone else is being harassed, or have any other concerns, you are encouraged to raise your concern in confidence with one of the Ombudspersons.

6

6

7 of 37

Reminder: IETF Mask Policy

  • Masks must be worn in meeting rooms and are recommended for common areas but not required.
  • In meeting rooms, masks may briefly be removed for eating and drinking, but that cannot be an excuse to leave them off for long periods.
  • In meeting rooms, active speakers, defined as those who are at the front of the room presenting or speaking in the mic queue, can remove their mask while speaking.
  • No exemptions for mask wearing, medical or otherwise, will be allowed.
  • Masks must be equivalent to N95/FFP2 or better, and free masks will be provided.

https://www.ietf.org/how/meetings/116/faq/#covidmeasures

7

8 of 37

About this meeting

8

9 of 37

Agenda

  • Preliminaries, Chairs (15 minutes)
    • Note Well(s), Note Takers, Participation hints
    • Agenda Bash
  • W3C WebTransport Update, Will Law, (15 minutes)
  • WebTransport over HTTP/2, Eric Kinnear (40 minutes)
  • WebTransport over HTTP/3, Victor Vasiliev (40 minutes)
  • Wrap up and Summary, Chairs & ADs (10 minutes)

9

10 of 37

W3C WebTransport Update (1)

​

​

10

10

W3C WebTransport WG progress since Nov 10, 2022

  • Status: Published a Working Draft - latest version March 14, 2023
  • Charter extension approved for additional year. New charter will expire Dec 31, 2023.
  • Timetable for year
    • June 30, 2023: Candidate for Recommendation - requires stability in API
    • August 2023: Proposed Recommendation - requires two independent implementations per our charter.
    • September 2023: Call for Review of a Proposed Recommendation
    • December 2023: Publication by W3C as a Recommendation after AC review
  • Milestone status
    • Candidate Recommendation (61% complete, 19 open (18 ready-for-PR), 30 closed)
  • Added new editor - Nidhi Jaju (Google)

​

11 of 37

W3C WebTransport Update (2)

​

​

11

Major decisions and updates since last IETF report (Nov 10):

    • Make WebTransportSendStream & WebTransportReceiveStream transferable #433 - allows transfer to and from workers. Restoring old behavior broken when subclassing readable/writeable.
    • Allow opening streams in parallel to the CONNECT request #440
    • Add sendOrder option to stream creation #441 #438 - sendOrder is a integer from (-2^63,+2^63)
      • If stream.sendOrder is null then this sending MUST NOT starve except for flow control reasons or error.
      • If stream.sendOrder is not null then this sending MUST starve until all bytes queued for sending on WebTransportSendStreams with a non-null and higher sendOrder, that are neither errored nor blocked by flow control, have been sent.
    • Add WebCodecs-Echo to the samples directory #430
    • Align WebTransportError with guidance. #460 - constructor signature changed. Affects our send abort API:
      • WAS writable.abort(new WebTransportError({streamErrorCode: WT_CODE}));
      • IS writable.abort(new WebTransportError("", {streamErrorCode: WT_CODE}));
    • Receiving a GOAWAY frame or DRAIN_WEBTRANSPORT_SESSION capsule #482 - await wt.draining will resolve once a WebTransport session receives a DRAIN_WEBTRANSPORT_SESSION capsule, or when an HTTP/3 GOAWAY frame is received.
    • Support BYOB Readers for Datagrams #487 - allows an application to supply its own buffer for single datagram. Recommended buffer size of 64KB. (max_datagram_frame_size from QUIC)

12 of 37

W3C WebTransport Update (3)

​

​

12

Firefox initial release of WebTransport support!

​

  • Firefox 113 (currently Nightly) supports WebTransport, including Datagrams
    • Congestion control is CUBIC
    • Protocol implementation is largely in Rust as part of our neqo http3 support
    • Passes almost all web-platform tests (and we’re adding more)
  • A few features haven’t landed yet:
    • SendOrder support
    • Outgoing Datagram timeouts and HighWaterMark/buffering details
    • BYOB readers for Datagrams (being added to the spec currently)
    • Some smaller details around error values
  • Demo with MOQ demo server (https://moq.streaming.university/)
    • (Turn on network.webtransport.enabled and network.webtransport.datagrams.enabled)

13 of 37

W3C WebTransport Update (4)

Current issues of debate:

  1. Adding sendRateEstimate feedback to wt.getStats() - an estimate of the maximum rate at which an application can write data and avoid queue build-up.
    • How frequently does the UA update this value?
    • Over what time window is this estimate valid?
    • Nullable aside, what is the initial sendRate?
    • When does it appear?
    • What is it if nothing is being sent?
    • Once non-null, can it go back to null? What should an app do in that case?

​

  • Client initiated drain #436 - “To drain a WebTransport session, either endpoint can send a DRAIN_WEBTRANSPORT_SESSION capsule. After sending or receiving a DRAIN_WEBTRANSPORT_SESSION capsule, an endpoint MAY continue using the session but SHOULD attempt to gracefully terminate the session as soon as possible.” Example: a client archiver app might not want lose streams in flight, and uses wt.drain() to tell server to stop creating new streams.
    • Is this behavior desired by IETF WebTrans? Should we add a API to allow an application to signal to the UA that it should initiate a drain?

​

​

14 of 37

W3C WebTransport Update (5)

Current issues of debate continued:

  • MAX_STREAM limit #446 - media applications can conceivably create more concurrent streams than the default UA stream limit (100?). The number of streams one side can open is based on the value of MAX_STREAMS sent by the peer.
    • Browsers need to set a default, which may not fit the needs of every application
    • Do we need an API to allow us to increase the # of allowable incoming streams the browser will accept or should the browser auto expand the limit?

​

  • Allow datagram send order relative to streams to be application defined #451 - we have added a send order number that, if provided, opts the created WebTransportSendStream in to participating in strict ordering. Bytes currently queued on strictly ordered WebTransportSendStreams MUST be sent ahead of bytes currently queued on other strictly ordered WebTransportSendStreams created with lower send order numbers.
    • Proposal is currently to add a similar property to Datagrams, such that they participate in the same send priority scheme as Streams. For example: wt.datagrams.sendOrder = 3;
    • Anticipate any problems with this approach?

​

​

​

​

15 of 37

WebTransport over HTTP/2

​

​

Eric Kinnear

https://datatracker.ietf.org/doc/html/draft-ietf-webtransport-http2

​

15

16 of 37

Since IETF 115

  • Capsule changes have landed
  • #64 Can now send any capsules allowed by flow control before CONNECT response (#38, #62)
  • #65 When a resource does not support WebTransport, respond with 406 Not Acceptable instead of 404 (#61)
  • #66 Added initial flow control windows using the WebTransport-Init HTTP header field (#63)
  • #77 Removed SETTINGS_ENABLE_WEBTRANSPORT in favor of SETTINGS_WEBTRANSPORT_MAX_SESSIONS from both sides (#73)

16

17 of 37

WebTransport-Init Header Field

Dictionary structured field

​

Initial flow control limit for

u: Unidirectional streams opened by remote

bl: Bidirectional streams opened by local

br: Bidirectional streams opened by remote

17

#66

18 of 37

Remaining Issues

Examples

Error handling

Flow control for newly created sessions

18

19 of 37

Error Handling #44

Proposal: Violations and other fatal errors cause a reset of the H2 stream, destroying the WebTransport session.

19

20 of 37

Initial Limits #71, #72

Problem: You can send any capsules allowed by flow control without waiting for a 2xx response.

​

In practice, this means a client can likely send only DATAGRAM and flow control frames.

20

21 of 37

Initial Limits #71, #72

Opportunity: Non-zero stream and data limits would allow both clients and servers to send reliable data in the first roundtrip.

21

22 of 37

Initial Limits #71, #72

Options:

Default initial limits for all implementations

Communicate initial limits in SETTINGS

22

23 of 37

Initial Limits #71, #72

Default initial limits for all implementations

Requires all implementations to support X streams, Y bytes on those streams

​

Choose value

Base on values sent in HTTP/2 SETTINGS

23

24 of 37

Initial Limits #71, #72

Communicate initial limits in SETTINGS

Allows each implementation to sign up for only as much data as is desired

Shared across all WebTransport sessions

Extra fun for intermediaries

24

25 of 37

WebTransport overview

WebTransport over HTTP/3

(40 minutes)

​

Victor Vasiliev

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3

​

25

26 of 37

Updates since IETF 115 (1)

Merged:

  • #86 Capsule design team output
  • #88 Add recommendation text for throttling
  • #87 Clarify SETTINGS behavior for 0-RTT
  • #93 Require sending SETTINGS_ENABLE_CONNECT_PROTOCOL
  • #94 Relax the Origin header requirement

26

27 of 37

Updates since IETF 115 (2)

Merged:

  • #96 Clarify the nature of WEBTRANSPORT_STREAM
  • #98 Clarify status code for Origin verification
  • #95 Document how to close both the session and the underlying connection
  • #106 Require SETTINGS_H3_DATAGRAM and max_datagram_frame_size

27

28 of 37

Resets and reliability #77

Blocked on QUIC WG

​

quic meeting:

Thu 9:30 - 11:30, G401-G402

28

29 of 37

Reset error code space #90

Options:

  • Do nothing
  • Expand space taken by “de-GREASE algorithm” from 8 bits to 32 bits
  • Use entire space (requires reset reliability)
  • Send the reset code in metadata blob attached to RESET_STREAM (requires metadata blob support)

29

30 of 37

Flow control #85

  1. Stream level – supported
  2. Total session data – only if dedicated/H2
  3. Number of streams – only if dedicated/H2

​

Do we want to support (2) and (3)?

If so, should we only support it in pooled only?

30

31 of 37

Support for HTTP redirects #61

Options:

  • Allow
  • Disallow
  • Allow but make clients handle it

Gotchas:

  • We allow sending data before receiving the HTTP status code

31

32 of 37

Priorities and Pooling #102

Consider:�

  • HTTP/3 connection has N WebTransport sessions
  • Each session has M streams, with relative prioritization��

How should the QUIC library prioritize these streams?

​

33 of 37

34 of 37

What if the WebTransport CONNECT requests have Priority with incremental off?

​

​

​

Most QUIC libraries don’t have an implementation rich enough to do anything other than “merge” right now.

35 of 37

What should the draft say?

Option 1: Nothing, you get what you get and don’t throw a fit�

Option 2: Streams are prioritized globally, be careful what you pool�

Option 3: WebTransport sessions are round robin, any stream prioritization is scoped within a session � What about HTTP request streams?�

Option 4: WebTransport sessions and HTTP request streams are prioritized by Priority header, any WebTransport stream prioritization is scoped within a session

36 of 37

Wrap-up, and Summary

(15 minutes)

​

​

Bernard Aboba

David Schinazi

36

37 of 37

Thank you

Special thanks to:

​

The Secretariat, WG Participants & ADs

37