1 of 41

WEBTRANS WG

IETF 112

Virtual Meeting

Tuesday, November 9, 2021

Session I, Room 2

12:00 - 14:00 UTC

04:00 - 06:00 Pacific Time

1

​

Mailing list: webtransport@ietf.org

Jabber Room: webtrans@jabber.ietf.org

MeetEcho: https://wws.conf.meetecho.com/conference/?group=webtrans

2 of 41

IETF 112 Meeting Tips

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

https://datatracker.ietf.org/meeting/agenda

This session is being recorded

  • IETF 112 registration and a datatracker login required to attend
  • No need to manually fill in blue sheets, it's automatic.
  • Join the session Jabber room via IETF Datatracker Meeting agenda
  • Please use headphones when speaking to avoid echo.
  • Please state your full name before speaking.

2

3 of 41

IETF 112 Meeting Tips

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

https://datatracker.ietf.org/meeting/agenda

This session is being recorded

  • 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

4 of 41

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:

​

4

5 of 41

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.

5

6 of 41

About this meeting

6

7 of 41

Other Meetings This Week

  • Media over QUIC (moq) side meetings:

7

8 of 41

Agenda

  • Preliminaries, Chairs (10 minutes)
      • Note Well, Virtual Bluesheets
      • Jabber Scribe, Note Takers
      • Speaking Queue Manager (David Schinazi)
      • Agenda Bash
  • W3C WebTransport Update, Jan-Ivar Bruaroey, (5 minutes)
  • WebTransport over HTTP/3, Victor Vasiliev (40 minutes)
  • WebTransport using HTTP/2, Eric Kinnear (40 minutes)
  • Hums, Wrap up and Summary, Chairs & ADs (25 minutes)

8

9 of 41

W3C WebTransport Update

​

​

9

W3C WebTransport WG progress since July 30th

  • Status: Published a Working Draft (i.e. no longer FPWD)
  • Finished all discussion of issues in minimum-viable-ship milestone
    • (4 non-editorial issues remain ready-for-PR, 3 editorial, 1 WPT)
  • Decisions & PRs
    • Shored up error handling in algorithms
      • New WebTransportError DOMException, with members:
      • source ("stream" or "session") and 8-bit streamErrorCode (=0)

�await upstream.abort(new WebTransportError({streamErrorCode: 123}));�

    • wt.datagrams.maxDataGramSize read-only UA integer
    • Sender-side now takes streams of BufferSource objects as input
    • Prioritized outgoing datagrams over outgoing streams
    • 32-bit close code: const {closeCode, reason} = await wt.closed;

10 of 41

W3C WebTransport Update (2)

​

​

10

  • TPAC (annual) meeting held Oct 26th - slides available here
  • Slides highlighting differences for those coming from a WebSocket and WebRTC background.
  • Chrome update - shipping WT support in M97
    • Built on -02 version of the draft. Has support for 8-bit reset streamCode errors, and error messages for closing the connection.
    • No origin trial required. Available in window & workers, secure context only.
    • Not shipping write prioritization and stats. Also hash-based certificates instead of WebPKI, may make it or be in M98.
    • Implementation is fairly mature. Covered by Web-Platform-Tests (WPT), using an echo server based on aioquic.
  • Multicast-for-the-web presentation by the W3C multicast CG with demo. Request to add multicast datagrams as a use-case.

11 of 41

W3C WebTransport Update (3)

​

​

11

Issue identified around bi-directional server-based video conferencing & low latency video upload from client to server:

  • Encoder and congestion control algorithms need to collaborate.
    • WebTransport Stats & API do not enable this today.
    • WebCodecs API “average bitrate target” results in overshoots (keyframe)/undershoots (delta frames).
  • An application can send less than what the congestion window will allow (by utilizing delay and bandwidth estimates), but cannot send more than what the congestion window permits.
  • Additive increase requires the application to slowly increase the sending rate to probe the network, however re-enabling dropped layers is a multiplicative increase.
  • Without application filling the congestion window (e.g. probing), the sender can get stuck at an artificially low rate.
  • Potential for conflicting congestion control loops: https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf

12 of 41

WebTransport over HTTP/3

(40 minutes)

​

Presentation End: 13:00

Victor Vasiliev

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

​

12

13 of 41

draft-02

  • Changes:
    • Support for clean session close
    • Reset error code mapping
    • Version negotiation header
    • Other fixes
  • Shipping in Chrome 97!

13

14 of 41

Version negotiation

Client offers Sec-WebTransport-Http3-Draft02: 1.

​

Server replies Sec-WebTransport-Http3-Draft: draft02.

14

15 of 41

Issue discussion

https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3

15

16 of 41

Issue #27: draining sessions

Should we add a GOAWAY capsule?

If so, what would it do?

16

17 of 41

Issue #22/36: pooling resources

How do we limit the resources allocated?

17

18 of 41

Issue #61: redirects

How should WebTransport clients handle 3xx responses?

​

(the conclusion during the last W3C discussion was to not support redirects)

18

19 of 41

Issue #63: request forgery

In WebSocket, we use masking to avoid confusion attacks on the intermediaries.

​

Do we need something similar in WebTransport?

19

20 of 41

Backup discussion slide

20

21 of 41

WebTransport using HTTP/2

(40 minutes)

​

Presentation End: 13:40

Eric Kinnear

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

​

21

22 of 41

Updates since IETF 111

-02 submitted

“Layered” design�New WT frames on HTTP/2 CONNECT stream

Welcome Martin Thomson!

22

23 of 41

Layered

23

24 of 41

Layered

24

25 of 41

WebTransport Frames

25

26 of 41

Frame Formats #29

Mirroring QUIC as closely as possible

However, some fields are not necessary

26

WT_RESET_STREAM Frame {

Type (i) = 0x04,

Length (i),

Stream ID (i),

Application Protocol Error Code (i),

Final Size (i),

}

27 of 41

Frame Formats #29

Length field

27

WT_RESET_STREAM Frame {

Type (i) = 0x04,

Length (i),

Stream ID (i),

Application Protocol Error Code (i),

Final Size (i),

}

28 of 41

Capsules #25

Sending DATAGRAMS over HTTP(/2) is being defined in MASQUE

​

With CAPSULEs:

  • Body of CONNECT stream will be a sequence of CAPSULEs (conveyed in DATA frames)
  • Each CAPSULE carries one WebTransport Frame�
  • DATAGRAM CAPSULE carries… WT_DATAGRAM?

28

29 of 41

What about Streams?

The CAPSULE over message body semantic is used as a fallback when the underlying transport doesn't support a construct natively�

  • HTTP/3 with H3 DATAGRAM extension does not use DATAGRAM capsule, uses the native feature instead

​

HTTP/2 has native streams

​

Should WebTransport streams use native HTTP/2 streams?

  • Today, no

​

29

30 of 41

Flow Control #27

  • HTTP/2 Connection
  • HTTP/2 Stream
    • All data allowed on the CONNECT stream, including control WT frames
  • WT_MAX_DATA
    • All stream data on the CONNECT stream (WebTransport Session)
  • WT_MAX_STREAM_DATA

30

31 of 41

Flow Control #27

31

32 of 41

Flow Control #27

32

33 of 41

Error Handling #44

Generally, yes.

​

33

34 of 41

Error Handling #44

Generally, yes.

​

Reuse HTTP/2? GOAWAY

WT over HTTP/3 shares error space with HTTP/3, maps code

​

​

34

CLOSE_WEBTRANSPORT_SESSION Capsule {

Type (i) = CLOSE_WEBTRANSPORT_SESSION,

Length (i),

Application Error Code (32),

Application Error Message (..8192),

}

35 of 41

Discuss

35

36 of 41

WebTransport using �HTTP Semantics

​

​

36

37 of 41

WebTransport

  • We’ve now defined a mechanism by which any HTTP Extended CONNECT request can carry WebTransport Frames
  • Where available, we can use native features
    • For example, datagrams
    • Also streams, sometimes
  • Should all mappings of WebTransport do the same thing?
    • HTTP/3

​

37

38 of 41

HTTP/3

  • In practice, this is not much different from what we have now

​

  • If you’re going through an intermediary, they don’t need to speak WebTransport
  • “Pooling” is no longer an issue

​

  • Do we negotiate which? Do we need to support both?

​

38

39 of 41

Discuss

39

40 of 41

Hums, Wrap-up, and Summary

​

Session End: 14:00

Bernard Aboba

David Schinazi

40

41 of 41

Thank you

Special thanks to:

​

The Secretariat, WG Participants & ADs

41