1 of 55

WEBTRANS WG

IETF 108

Virtual Meeting

Monday, July 27, 2020

14:10 - 15:50 UTC

7:10 - 8:50 AM Pacific Time

Virtual Room 1

​

1

​

Mailing list: webtransport@ietf.org

Jabber Room: webtrans@jabber.ietf.org

MeetEcho link: http://www.meetecho.com/ietf108/webtrans/

2 of 55

IETF 108 Meeting Tips

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

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

https://www.ietf.org/media/documents/Documentation-Meetecho-IETF.pdf

This session is being recorded

  • IETF 108 registration and a datatracker account is required to join the meeting.
  • Your name will be automatically added to the attendee list based on your datatracker login.
  • Join the session Jabber room via IETF Datatracker Meeting agenda
  • When entering the queue, you need to select audio, video or both.
  • When you are called on, you need to enable your audio to be heard.
  • Please use headphones when speaking.
  • Please state your full name before speaking.

2

3 of 55

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:

​

3

4 of 55

About this meeting

4

5 of 55

Agenda

  • 14:10 – 14:20 Preliminaries, Chairs (10 minutes)
      • Note Well, Virtual Bluesheets
      • Jabber Scribe, Etherpad Note Takers
      • Speaking Queue Manager (David Schinazi)
      • Agenda Bash
      • W3C WebTransport Update
  • 14:20 - 14:30 WebTransport Use Cases, Will Law (10 minutes)
  • 14:30 - 14:50 WebTransport Overview and Requirements, Victor Vasiliev (20 minutes)
  • 14:50 - 15:05 WebTransport using HTTP/2, Eric Kinnear (15 minutes)
  • 15:05 - 15:20 WebTransport over QUIC, Victor Vasiliev (15 minutes)
  • 15:20 - 15:35 WebTransport over HTTP/3, Victor Vasiliev (15 minutes)
  • 15:35 - 15:50 Wrap up and Summary, Chairs & ADs (10 minutes)

5

6 of 55

W3C WebTransport Update

​

​

6

  • The WorkGroup Charter has been published at https://w3c.github.io/webtransport-charter/charter.html
  • Charter process is underway and voting is expected to complete today (July 27), with next steps in WG creation in August
  • Timeline
    • September 2020: First teleconference
    • January 2021: FPWD for WebTransport
    • Q2 2022: CR for WebTransport
    • Q? 2023: Expected completion
  • Use-case document being developed, to drive both W3C API and guide IETF development.
  • Two Co-Chairs have been nominated in anticipation of WG establishment

Jan-Ivar Bruaroey

Mozilla

Will Law

Akamai

7 of 55

WebTransport Use Cases

(10 minutes)

​

Presentation End: 14:30

Will Law

7

8 of 55

Many cited use cases over the past two years

​

Collected these for organisation in to a temporary home at https://docs.google.com/document/d/1ns2NhdqRQsARLy54ilkVXAlnm0y6mcaPj6sEphuzIsM/edit?usp=sharing

​

This will be moved via PR to https://github.com/WICG/web-transport for curation and debate.

8

9 of 55

Use-cases

(Ordinality of listing does not imply priority)

  • Machine learning - data IO to cloud ML processing
    • Speech translation/emotion analysis - sending audio/video data from client to server for analysis and receiving translated data/text/audio in return.
    • Security camera analysis - data and/or video sent to cloud service for analysis. Service may return data instructions.
    • QuicTransport use case

​

  • Multiplayer Gaming - web and consoles
    • Game play instructions sent from client to cloud based game engine. Some instructions are time sensitive (such as location data) , others are stateful (avatar selection). Dataflow is bi-directional.
    • Mixture of client-server and p2p data flows.
    • AR gaming requires real-world interaction, including virtual theatre - geo-separate actors with virtual backgrounds.
    • QuicTransport use case

9

10 of 55

Use-cases

(Continued)

  • Low-latency live streaming
    • Unidirectional Broadcast - one to many millions - sports events, news, wagering, latency < 1000ms to preempt social media and quality to support UHD, HDR, HFR, DRM.
    • Bi-directional few-to-few video chats via server, reduced connection time/complexity compared to WebRTC. Example - Apple Facetime™
    • QuicTransport or Htt3Transport?

​

  • Cloud Game Streaming
    • Server-side game rendering (such as Google Stadia™) transmitted to thin client with low latency (<60ms)
    • Bi-directional Game play instructions (both server and p2p).
    • QuicTransport use case.

​

​

10

11 of 55

Use-cases

(Continued)

  • Server-based video conferencing
    • Simpler session establishment
    • Censorship circumvention - preventing fingerprinting and identification during session establishment.
    • QuicTransport or Htt3Transport?

​

  • Remote desktop
    • Transmission of screen capture/sharing and control instructions.
    • Collaborative work on a shared screen.
    • Including scaling to very large audiences.
    • Online document sharing - synched mouse location + edit state
    • Remote assistance temporarily "taking over" control of a system
    • Client/server or P2P
    • QuicTransport Use Case

​

​

​

11

12 of 55

Use-cases (Continued)

  • Time Synchronized Multimedia Web communications
    • Combining geo-separate singing and/or instruments together online with precise time synchronization.
    • QuicTransport or Htt3Transport?

​

  • IOT sensor and analytics data transfer
    • Efficient and intermittent transmission of data. For example - sending a 1 bit flag, GPS position updates, mouse clicks on site etc.
    • Sensor data upload - including filters, aggregation, triggers.
    • QuicTransport Use Case

​

  • PubSub Models - avoid long-polling
    • Social feeds - Twitter™ , financial tickers etc.
    • Messaging platforms, including Enterprise messaging infrastructure
    • Http3Transport Use Case

​

​

​

​

12

13 of 55

Use-Case issues

  • Which of these use-cases
    • can be solved sufficiently well using existing technologies?
    • can be solved by extending existing technologies (websocket, WebRTC)?
    • warrant the development of a new technology?
    • are best handled via QuicTransport? Http3Transport?
  • Who curates goals and non-goals between IETF and W3C?
  • Encourage WebTransport to do a few things really well

​

We look forward to fruitful collaboration between IETF and W3C WG on WebTransport development.

13

14 of 55

WebTransport Overview and Requirements (20 minutes)

​

Presentation End: 14:50

Victor Vasiliev

https://tools.ietf.org/html/draft-ietf-webtrans-overview

​

14

15 of 55

Goal of this document

“To assist in the coordination with owners of the WebTransport API, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort. The requirements will include those arising from the WebTransport API.”

(from the charter)

15

16 of 55

Updates since last IETF

16

17 of 55

Issue #1: stream IDs

Need a consistent model for all transports.

Current text:

“Every stream within a transport has a unique 64-bit number identifying it. Both unidirectional and bidirectional streams share the number space. The client and the server have to agree on the numbering, so it can be referenced in the application payload. WebTransport does not impose any other specific restrictions on the structure of stream IDs, and they should be treated as opaque 64-bit blobs.”

17

18 of 55

Issue #1: stream IDs

Why are stream IDs hard?

  • Proxying
    • Have to preserve stream IDs in case new streams are opened out of order
    • In multiplexed transports (H2/H3) 1:1 correspondence is impossible
  • Information disclosure
    • When multiple origins accessed over same connection, HTTP-level stream IDs reveal their state

18

19 of 55

Issue #1: stream IDs

What is the use case for stream IDs?

​

Developers who asked for it care mostly about knowing the ordering between streams, rather than using them as on-the-wire reference.

19

20 of 55

Issue #2: stream resets

  • In HTTP/2, resetting a stream resets both halves
  • In QUIC, resetting a stream causes the write half being closed, STOP_SENDING causes read half being closed
  • Options:
    • Require WebTransport over QUIC/H3 automatically close other half
    • Port STOP_SENDING to HTTP/2

20

21 of 55

Issue #3: streams, messages

WebTransport uses streams of bytes as a primitive, since that’s what QUIC and HTTP/{2,3} use.

Problem: WebSocket/RTCDataChannel use streams of messages.

Do we want to provide that as an additional primitive?

21

22 of 55

Other TODOs in the draft

  • Currently missing sections:
    • Explicit state machine description
      • Depending on resolution of #2, this would look either like QUIC or like HTTP/2
    • Missing section on priorities

22

23 of 55

Discussion

23

24 of 55

WebTransport using HTTP/2

(15 minutes)

​

Presentation End: 15:05

Eric Kinnear

https://tools.ietf.org/html/draft-kinnear-webtransport-http2

​

24

25 of 55

25

26 of 55

26

27 of 55

27

28 of 55

28

29 of 55

29

30 of 55

30

31 of 55

31

32 of 55

32

33 of 55

33

34 of 55

34

35 of 55

35

36 of 55

WebTransport over HTTP/3

WebTransport over QUIC

(30 minutes)

​

Presentation End: 15:35

Victor Vasiliev

https://tools.ietf.org/html/draft-vvv-webtransport-http3

​

36

37 of 55

Http3Transport

...is like Http2Transport, but over HTTP/3!

  • Datagram support using draft-schinazi-quic-h3-datagram-03
  • Draft is currently in process of being converged towards design choices outlined in draft-kinnear-webtransport-http2-01:
    • SETTINGS-based negotiation
    • Using stream IDs to associate WebTransport streams with a Connect stream
    • WebTransport streams can have optional headers and trailers

37

38 of 55

QuicTransport

Minimal protocol on top of QUIC

  • ALPN value (“wq”)
  • URI scheme
  • Client indication (special stream with metadata)
    • Contains origin of the initiating webpage
    • Contains the path from the URI
  • One dedicated QUIC connection per transport session

38

39 of 55

QuicTransport URI scheme

39

quic-transport://server.test:50000/test?foo=bar

sent as SNI

sent in client indication

40 of 55

QuicTransport origin trial

Available in Chrome 84-86!

​

https://web.dev/quictransport/

​

Implements QUIC draft-27 (draft-29 starting Chrome 85).

40

41 of 55

The Great Transport Zoo

Season 2

41

42 of 55

Transports proposed so far

  • QuicTransport�A QUIC connection with minimal additions required to make it work with Web security model.
  • Http2Transport�Virtual multiplexed transport inside an HTTP/2 connection.
  • Http3Transport�Virtual multiplexed transport inside an HTTP/3 connection.
  • FallbackTransport (no draft currently)�Simulation of multiplexed streams on top of WebSocket protocol

Which ones do we actually need?

42

43 of 55

Overview of proposed transports

43

​

Dedicated

Pooled

QUIC-based

QuicTransport

Http3Transport

TCP-based (fallback)

FallbackTransport

Http2Transport

44 of 55

QuicTransport vs Http3Transport

QuicTransport:

  • Dedicated connection
    • Transport fine-tuning on server
    • More stats exposed to client
  • No HTTP/3 dependency
  • Target applications:
    • Machine learning
    • Video games on the Web
    • Live streaming
    • Real-time media
    • IoT

Http3Transport:

  • Pooled with other HTTP/3 traffic
  • HTTP features:
    • Use HTTP load balancing and routing
    • Headers for metadata
  • Target applications:
    • General web applications
    • Web chats
    • Push notifications

44

45 of 55

Advantages of HTTP transports

  • Multiplexing support
    • Support for multiplexing Http3Transport and HTTP/3
    • Reduces number of QUIC/TCP sockets in use
    • Lower startup cost for new transports
    • Traffic appears identical to HTTP to the network

​

Note that multiplexing being supported does not automatically imply it being required

      • When dedicated connection is beneficial, this could be controlled at the API layer

45

46 of 55

Advantages of HTTP transports

  • Shared metadata format
    • Can reuse HTTP headers and status codes
    • Standard headers that are useful:
      • Origin
      • Location
      • Forwarded
      • :path/:authority/:scheme
    • Custom headers can be reused as-is
    • Counterpoint: similarity of HTTP can lead to wrong expectations

46

47 of 55

Disadvantages of HTTP

  • Implementation complexity
    • Most comes from HPACK/QPACK
    • Can be solved by making header compression support negotiable
    • Multiplexing is harder to implement in browsers
  • Design complexity
    • Have to define interaction with existing HTTP mechanisms
    • Pooling and flow control can lead to DoS
    • Things like stats are easier to define with dedicated connections

47

48 of 55

Implementation experience

  • QuicTransport
    • Implemented in Chrome
    • Various server implementations
    • Easy to implement on top of an existing QUIC library (100-200 lines for Python)
  • HttpTransport
    • Variations implemented at Facebook and Apple
    • No in-browser support for the clients currently

48

49 of 55

Use cases

  • Both options satisfy the WebTransport requirements, notably unreliable datagrams and streams without head-of-line blocking
    • Those two properties are key for satisfying the enumerated use cases
  • Other aspects may make individual transports a better fit for specific use cases:
    • HTTP-based options are more attractive to the operators of large server setups
    • Raw QUIC-based option is more attractive to people who would want to implement this from scratch (e.g. game developers)

49

50 of 55

Beyond wire protocol

  • What URL scheme would the resulting resources be represented by?
    • Determines whether WebTransport and HTTP are same-origin
  • Handshake-level concerns
    • Do we send cookies?
    • HTTP auth, TLS client certs, etc
    • Alt-Svc and socket pool integration

50

51 of 55

Next steps

  • The current discussion is between two options: “only QUIC” and “only HTTP”
  • Need more input from wider audience of Web developers
  • Current plan: continue discussion on the mailing list
  • Potential focus of an interim meeting?

51

52 of 55

Discussion

52

53 of 55

Wrapup and Summary

(15 minutes)

​

​

Session End: 15:50

Bernard Aboba

David Schinazi

53

54 of 55

Thank you

Special thanks to:

​

The Secretariat, WG Participants & Chairs

54

55 of 55

WEBTRANS WG

IETF 108

Virtual Meeting

Monday, July 27, 2020

14:10 - 15:50 UTC

7:10 - 8:50 AM Pacific Time

Virtual Room 1

​

55

​

Mailing list: webtransport@ietf.org

Jabber Room: webtrans@jabber.ietf.org

MeetEcho link: http://www.meetecho.com/ietf108/webtrans/