Devtools for WebTransport

[Yoichi Osato]

Abstract

This document proposes the Chrome DevTools support for WebTransport. 

Since WebTransport supports two protocols and can create two or more streams over them, the DevTools should show them well structured.

Scenarios

We list some scenarios where web developers want to inspect WebTransport.

1. (P1) See sent headers when the opening handshake succeeded or failed. 

2. (P1) Watch Http3/Quic connections

1. start/connect/abort

3. (P2) Watch send/receive streams over the connections

1. start/abort

Network timeline (P1)

The network timeline covers the scenario #1 and #2.

When a WebTransport object is created with a URL, we start a Http3/Quic connection. Then the network timeline lists the connection.

Each item shows

• URL

• protocol

• Headers of opening handshake

An item is alive when the associated connection is alive.

Waterfall bars might show colors depending on its state (handshaking, streaming and abort)

WebTransport Streams viewer (P2)

For scenario #3, we will show streams associated with each connection in another new panel like WebSocket.

(or should they also be shown in the above network timeline?)

Unlike WebSocket, one connection can have two or more streams.

• OutgoingStream

OutgoingStream has a WritableStream to send data to the server

• Lifecycle waterfall

• Created/ Abort (StreamAbortInfo)

• IncomingStream

IncomingStream has a ReadableStream to receive data from the server

• Lifecycle waterfall

• Created/ Abort (StreamAbortInfo)

• BidirectionalStreams

BidirectionalStream has an OutgoingStream and an IncomingStream.

• Datagram WritableStream

• Datagram ReadableStream

[Yoichi Osato]

Please let me add something here.

• I'm a Chrome engineer and I'd like to implement a new feature on Devtools to support WebTransport debugging as Yutaka proposed.
• Above is the current design I have.
• I would appreciate any feedback on the design, especially if you're a current WebTransport user. To make our discussion productive, please feedback at https://bit.ly/3ig8BLi.
  

Regards.

2020年9月28日(月) 14:38 Yoichi Osato <yoi...@chromium.org>:

[Yutaka Hirano]

We, the implementation team, would appreciate any feedback on the proposal, as web developers probably have better ideas about devtools features than us.

Thanks,

--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/CAAEV3pm0ZtR%2Bi14k54StiunG%2B1FWOi-ah9dC2u96S9md1_9DcA%40mail.gmail.com.

[Luke Curley]

Hey Yoichi and Yutaka, thanks for putting this together.

1. Putting WebTransport connections on the network timeline sounds great and I see no problems there.

2. I haven't used WebSockets in a long time so I can't speak as to the effectiveness of the devtools page. Datagrams could use the WebSocket panel almost verbatim, but streams will need something different. 

Part of the problem with streams is that they can be used in different ways. One developer may keep a single stream open and occasionally append new messages (pipelining). Another developer may open a stream for each new message, writing the data and then immediately closing the write end of the stream (like HTTP/3). The timeline of data transferred is the same in both cases, but it's spread out over a different number of streams. Also like you mentioned, there needs to be support for bidirectional streams.

Personally, I would make something similar to the network tab. Each stream would be a different row similar to an HTTP request. The waterfall could have two vertically-stacked bars, one for outgoing data and one for incoming data (depending on the stream type). The incoming and outgoing end of the stream both have their own lifecycle that would be great to visualize (for the single-message use case). I would like to see the entirety of data that has been sent or received over each stream thus far.

It's more difficult, but I would also like to know when specific sections of a stream were transmitted (pipeline case). I seem to remember Wireshark doing something for TCP where it would show you the entire stream, and you could click on an individual packet to overlay the offset+size bounding box. To translate that idea to QUIC, you could render each STREAM frame (or cluster) on the timeline to both demonstrate spurious network activity, and allow zooming in to see the specific contents (kind of like a trace)

Hope that helps!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/CABihn6FdA93CMd88sPoLJJMr2cvX2C%3DP0noXuRnTswNR-xLnQg%40mail.gmail.com.

[Lucas Pardue]

On Fri, 2 Oct 2020, 22:50 Luke Curley, <kixe...@gmail.com> wrote:

It's more difficult, but I would also like to know when specific sections of a stream were transmitted (pipeline case). I seem to remember Wireshark doing something for TCP where it would show you the entire stream, and you could click on an individual packet to overlay the offset+size bounding box. To translate that idea to QUIC, you could render each STREAM frame (or cluster) on the timeline to both demonstrate spurious network activity, and allow zooming in to see the specific contents (kind of like a trace)

WebPageTest is able to show data reception on streams. This has been very useful for understanding how HTTP/2 servers are scheduling data when there is stream multiplexing. (We used this to help understand HTTP/2 prioritization)

In QUIC, we've benefitted from qvis https://qvis.edm.uhasselt.be/#/files, which can generate a few different types of visualizations for different protocol aspects. The multiplexing and packetization views help understand some of the things Luke mentioned.

Lucas 

[Yoichi Osato]

Thank you for your feedback!

I understand there is a demand to watch each stream. From the performance perspective, I'm planning to only show each stream lifecycle excluding each chunk data (we can show the timing of the data foreach).

2020年10月3日(土) 7:04 Lucas Pardue <lucaspar...@gmail.com>:

[Yutaka Hirano]

Thank you for the feedback.

1. Transport vs. Stream

Yeah, it's difficult. For regular HTTP/2 and HTTP/3 streams, one row corresponds to one stream, and one stream has HTTP request and response.

On the other hand, for WebTransport, There is one handshake per transport, not stream. I don't have a strong opinion which is better.

2. Data chunks in stream

As you say, we can see each message for WebSocket, but in order to implement the feature we need to keep each message indefinitely. This costs memory and some web developers are not happy with that - please see https://crbug.com/594950.

So we have several ways I think:

 A. Do not implement a feature to show each chunk, and do not store chunk data (the current design).

 B. Implement a feature to show each chunk.

   a. Store each chunk indefinitely. (the WebSocket way)

   b. Have a fixed limit (the number of chunks, the number of total bytes, the duration, ...)

   c. Have a UI to customize the behavior.

On the initial design we chose A because it was the easiest. Do you have a preference in B?

[Lucas Pardue]

FWIW, knowing the send/receive time and size of a chunk would probably go a long way to helping debugging. And cut down on 90% of the storage concerns.

[Yoichi Osato]

Saving only the time and size of each chunk sounds good to balance memory and debuggability.

2020年10月5日(月) 19:17 Lucas Pardue <lucaspar...@gmail.com>:

[Luke Curley]

Yeah, I don't think it needs to be perfect the first time around. The chunk timings and sizes are still useful information.

[Robin MARX]

Hello all,

Sorry I'm late to the party on this. I am the developer of the QUIC tools Lucas mentioned earlier (https://qvis.edm.uhasselt.be/) and have some thoughts on this.

a) I'm not sure what you mean above Yutaka, when you say "for h2 and h3 one row corresponds to one stream" ... "for WebTransport, there is one handshake per transport, not stream". 

     For H2 and H3, there is also only one handshake for multiple streams? So I'm not sure why the existing row-based approach wouldn't work there. Could you give more details?

b) I am also strongly in favor of showing per-chunk information. One of my main gripes with Chrome's devtools is that it just shows request start and finish and not potentially idle periods in between to e.g., make clear resource multiplexing in H2/H3.

    However, when making such tools myself, I have found it's difficult plotting chunks on a timeline correctly. If you use the typical timeline, your x-axis is time, not size. 

    So while it seems intuitive to plot chunks on the timeline as rectangles and have the width of each chunk correlate with its size, this doesn't really work that well in practice.

    This is especially true as with congestion control, a lot of data can be sent at a short time, and this amount of data fluctuates throughout the connection. As acks/partial responses come in, new data might be queued while other data is still in-flight etc. so you end up with overlapping chunks. I haven't found a good way of showing those in a proper way without loosing a lot of vertical space. 

    It quickly gets to a point where the visualization is no longer representative of what's actually happening on the network. It depends on the use case whether this matters or not. For example, it might be fine if you just want to show the application-layer sending behaviour (not caring about when it actually is put on the wire), but that potentially doesn't work too well if you're doing that for receiving data in a streaming fashion. The main problem then is how to make sure users understand what you're actually showing at which level of detail/accuracy. 

    IIUC, WebPageTest bypasses/"solves" some of this by calculating the available bandwidth from a packet capture and deriving a plausible width of their chunks on a timeline basis for this, but I'm not convinced how robust this is / if it can be applied to a "live" visualization without access to a bandwidth/cwnd estimator. 

    So, long story short, in qvis we don't use a timeline but rather employ size as the x-axis and just append all received QUIC streams/packets on that single line. That way, you get things like the screenshots on this page: https://h3.edm.uhasselt.be/ (each color is a separate H3 stream carrying a resource)

    This works really well for assessing multiplexing/prioritization behaviour of streams on a single connection (where the real timing doesn't matter all that much), but might not be ideal for general WebTransport debugging.

    

    One potential solution I've considered is to allow the user to toggle between timeline-based and size-based views (where on the timeline, each chunk is rendered equally sized, no matter what its real size is)

    Another option could be to detect time "gaps" between chunks and render chunks that are close enough to each other as contiguous blocks (so showing more like idle vs non-idle behaviour per stream). However, that potentially fails when sending lots of smaller chunks in quick succession (e.g., a fast-paced multiplayer game)

   I would be very interested in hearing from others with experience in this type of thing if there are better solutions and/or to help figure this out for the Chrome devtools

Best regards,

Robin

[Yutaka Hirano]

On Wed, Oct 7, 2020 at 10:25 PM Robin MARX <robin...@uhasselt.be> wrote:

Hello all,

Sorry I'm late to the party on this. I am the developer of the QUIC tools Lucas mentioned earlier (https://qvis.edm.uhasselt.be/) and have some thoughts on this.

a) I'm not sure what you mean above Yutaka, when you say "for h2 and h3 one row corresponds to one stream" ... "for WebTransport, there is one handshake per transport, not stream". 

     For H2 and H3, there is also only one handshake for multiple streams? So I'm not sure why the existing row-based approach wouldn't work there. Could you give more details?

I wanted to say, for HTTP/2 and HTTP/3, each row corresponds to an HTTP/2 and HTTP/3 stream. There would be a difference between an HTTP stream and a WebTransport stream though - We have an HTTP request and HTTP response for each HTTP stream, but there is no handshake for each WebTransport stream. This may be confusing to web developers.

[Yoichi Osato]

Thank you very much for your feedback. I’ve decided to list both connections and streams on the network timeline.

We'll show the size and timestamp for each sent/received chunk in a subpanel in the stream view.

Whole design is here: https://bit.ly/3ig8BLi

I'll start implementing the feature, but we'll continue appreciating your feedback and suggestions.

Cheers.

2020年10月7日(水) 22:36 Yutaka Hirano <yhi...@chromium.org>:

[Robin MARX]

Hello Yoichi,

I think the proposed approach looks good. Listing the chunks separately in tabular form isn't as fancy as other options, but bypasses many of the problems and should work fine in practice. 

I've left a few nits as comments in the document. 

Looking forward to seeing this in the devtools!

With best regards,

Robin

[Yoichi Osato]

Thanks Robin.

Yes, how we might show each chunk is one of the most important UX issues.

Due to our bandwidth, reusing the similar UX component for WebSocket is the current way.

Also thanks for document comments. 

Cheers.

2020年10月15日(木) 18:08 Robin MARX <robin...@uhasselt.be>:

[Yoichi Osato]

Hi. 

I implemented very basic connection info in DevTools: you can see "webtransport" item in the Network panel

So far it shows a waterfall bar and time. This has been enabled from M89.

I'm going to implement more features on that and so far, I'm considering handshake info.

As WebTransport sessions are established over HTTP/3, I think it is good to show HTTP CONNECT request/response headers as well as typical fetch:

Any thought/feedback/opinion is welcome.

Thanks.

2020年10月16日(金) 9:50 Yoichi Osato <yoi...@chromium.org>: