Send Datagrams dropped

[James Bankoski]

Hi WebTransport team,  

The zoom folk  ( cc'ed) on this email are trying to move sending their compressed data off main thread to improve performance and hoped to use web transport to accomplish this but bumped into issues with the implementation that resulted in too much packet loss  

see https://github.com/w3c/webtransport/issues/152

Can you please look into the issue and see if there's anything that can be done?

Jim 

[Tony Zhen]

as our member report in https://github.com/w3c/webtransport/issues/152, many datagrams are easily dropped in quic stack.

after study the stack, we found it was dropped in  QuicDatagramQueue::RemoveExpiredDatagrams()

in  quic_datagram_queue.cc . due to GetMaxTimeInQueue return 4ms. so many datagrams are easily expired in queue.

the test was carried on in our local network.

anyway I think the GetMaxTimeInQueue returns an unreasonable value in some cases.

could web-transport provide a way by which the application can set this max value in js ?

--
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/CANzSYSc7nHKmQmFAoDe3Ao-p%2Bbx-7C_c264BMCrWHCiO0VPvJg%40mail.gmail.com.

[Yutaka Hirano]

Thank you!

Datagrams are stored in the QuicDatagramQueue of the connection.

1. Bring the backpressure information to JS. This means if there are a lot of datagrams in the queue (let's say "the queue is full"), writer.ready will not be resolved.

2. Allow JS to control the timeout value.

3. Allow JS to control the queue length which is used to decide whether the queue is full or not.

I'm working on 1. I can provide experimental APIs for 2 and 3. What do you think?

If these are proven to be effective we will be able to bring the data to  https://github.com/w3c/webtransport/issues/152.

[Luke Curley]

Back pressure would be amazing!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/CABihn6H%3DJ%2Bk-Lz4sRM%3D7snL%2BXddoz1Suo_Rt%3Df9mXTge2wPacQ%40mail.gmail.com.

[Yutaka Hirano]

Sorry for the long silence.

I landed some CLs that provide more control for outgoing datagrams.

 1. writer.ready is not fulfilled when we have N outgoing datagrams each of which is neither sent nor discarded due to timeout.

 2. N is configurable via the `datagramWritableHighWaterMark` member in the QuicTransportOptions dictionary.

 3. The timeout duration is configurable via WebTransport.setDatagramWritableQueueExpirationDuration.

I believe they are what you were looking for. Please let me know if you have any questions or comments.

These are non-standard APIs. If they are proven to be useful I'll bring them up to the standard, so your feedback will be greatly appreciated.

Thanks,

[Yutaka Hirano]

I forgot to say, they are available on 89.0.4943.0 and later.

[Tony Zhen]

I have to update our quic server to support draft29 before testing these js api.

current we support draft 27.

It will need time.

[Tony Zhen]

Hi Yutaka

we just finished updating our quic server to draft 32.

I installed latest chrome canary, whose version is 89.0.4365.0 canary （64 bit）

but test print error 'Uncaught SyntaxError: Invalid or unexpected token' when run 'setDatagramWritableQueueExpirationDuration(double ms)'.

I guess this version did not include the modifications.

How can I install canary version 89.0.4943.0?  because you said the modification will be available in 89.0.4943.0.

Best regards,

Tony Zhen

[Tony Zhen]

   the canary also did not recognize below api. 

readonly attribute WritableStream datagramWritable;

readonly attribute ReadableStream datagramReadable;

if the chromium built by myself based on latest code also could not recognize the new api and above two api.

we are using WebTransport,  it can recognize WebTransport.

transport = new WebTransport(url);

[Bernard Aboba]

Did you set chrome://flags or edge://flags to enable “Experimental Web Platform features”? The following website definitely works with the below attributes on the latest builds of Chrome or Edge Canary:

https://webrtc.internaut.com/quic/newtrial2.html

This is the Complete Example in Section 14.5 of the spec:

https://w3c.github.io/webtransport/#example-complete

Just tried it on Chrome Canary 89.0.4365.0 and it runs fine.

On Dec 23, 2020, at 18:43, 'Tony Zhen' via web-transport-dev <web-tran...@chromium.org> wrote:



<image.png>

the test was carried on in our local network.

anyway I think the GetMaxTimeInQueue returns an unreasonable value in some cases.

could web-transport provide a way by which the application can set this max value in js ?

On Fri, Nov 13, 2020 at 12:09 AM 'James Bankoski' via web-transport-dev <web-tran...@chromium.org> wrote:

Hi WebTransport team,  

The zoom folk  ( cc'ed) on this email are trying to move sending their compressed data off main thread to improve performance and hoped to use web transport to accomplish this but bumped into issues with the implementation that resulted in too much packet loss  

see https://github.com/w3c/webtransport/issues/152

Can you please look into the issue and see if there's anything that can be done?

Jim 

--
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/CANzSYSc7nHKmQmFAoDe3Ao-p%2Bbx-7C_c264BMCrWHCiO0VPvJg%40mail.gmail.com.

--
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/CABihn6H%3DJ%2Bk-Lz4sRM%3D7snL%2BXddoz1Suo_Rt%3Df9mXTge2wPacQ%40mail.gmail.com.

--
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/CAG97Dgs498h1hKTyyu3MafS552TYko10Yd3TzifJ1EkrNW02xA%40mail.gmail.com.

[Tony Zhen]

after enable it in chrome://flags, I can test it now.

I start chrome with below cmd. I thought it could enable web-platform-features.

chrome.exe --enable-experimental-web-platform-features --enable-quic --quic-version=h3-27 --origin-to-force-quic-on=quictest.zoomdev.us --enable-logging --v=1

thanks

[Yutaka Hirano]

It sounds like you are using QuicTransport, not WebTransport.

Please see this message for the relationship between these two interfaces. Although I didn't remove QuicTransport, I'm going to add new APIs only to WebTransport. 

Thanks,

[guest271314]

> https://webrtc.internaut.com/quic/newtrial2.html

Note, window.currentTransport is undefined at the linked page. currentTransport is defined using let, which is not the same scope as window. This page has the complete example as well https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport.

[Tony Zhen]

@Yutaka Hirano 

Our final tests prove the new APIs work fine. 

Currently there is no datagram dropped if set proper value with new APIs.

Please help to bring them to the standard.

Thank you so much

[Thomas Nattestad]

+Dale Curtis FYI 

[Yutaka Hirano]

Thank you! 

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

[Tony Zhen]

@Yutaka Hirano 

do you know when these new APIs are available in chrome ?

chrome 88 dose not include them.

thanks

Best Regards,

Tony Zhen

[Yutaka Hirano]

They are available on 89.0.4943.0 and later.