Re: [AVTCORE] Response to W3C WebTransport WG Request from IETF 112

[Bernard Aboba <[e-mail]>]

Sergio said:

"I don't think that the webtransport api and the browser stack should have
this information, it is completely up to the application to control what is
the behaviour based on the current bw estimation.

Moreover, I doubt that the webtransport stack could provide a valid bw
estimation usable by the app at all.

IMHO the bwe needs to be calculated at the js app level and just needs the
quic cc not mess too much and if possible provide the reception time stats
for the sent packets"

[BA] It is left to the Javascript application to decide the transport mode,
audio/video multiplexing approach, loss recovery strategy and mechanism for
controlling the encoder rate.  The WebTransport API doesn't know and
doesn't care whether the transported media is G711, G722, Opus, VP8/VP9,
H.264, AV1, etc. Currently there is no priority support, so it's up to the
application how to apportion the bandwidth between audio and video streams.

The current WebTransport stats are very bare bones:
https://w3c.github.io/webtransport/#web-transport-stats
https://w3c.github.io/webtransport/#web-transport-stats%E2%91%A0

Some stream stats are in the works (see:
https://github.com/w3c/webtransport/pull/395) but they also aren't
elaborate (at least compared with WebRTC-stats).

You'll notice there is no bandwidth estimate, nor is any info provided on
acknowledgements or reception times.  Since a Javascript application using
the WebTransport API is not integrated with the QUIC stack, info on ACKs
was not considered relevant since the application could not be presumed to
have received a datagram just because it was ACK'd at the QUIC layer; the
datagram could have been subsequently dropped in the browser datagram
reception queue after being ACK'd.  Similarly, in the browser, the
reception time doesn't reflect the total one-way delay because there are
additional delays and queues both on the sender and receiver side.


 However, the receiver can calculate the goodput on  streams and datagram
flows and provide this info to the sender to help with encoder rate
adaptation.

On Mon, Apr 11, 2022 at 12:10 PM Sergio Garcia Murillo <
[e-mail]> wrote:

>
>
> El lun, 11 abr 2022 18:19, Stephan Wenger <[e-mail]> escribió:
>
>> Inline in blue.
>>
>> S.
>>
>>
>>
>>
>>
>> On 4/11/22, 08:24, "avt on behalf of Jonathan Lennox" <
>> [e-mail] on behalf of [e-mail]> wrote:
>>
>>
>>
>>
>>
>>
>>
>>     > On Apr 11, 2022, at 1:34 AM, Spencer Dawkins at IETF <
>> [e-mail]> wrote:
>>
>>     >
>>
>>     > But even if we don't need to choose between media-oriented
>> congestion controllers, we would need a QUIC extension to allow us to say
>> "we're doing media, so don't use the congestion controllers you might use
>> for non-media traffic".
>>
>>     >
>>
>>     > I suspect the QUIC working group would be a fine place to work on
>> that extension (and if we did it anywhere else, QUIC would either ask, or
>> be asked, to review that work anyway).
>>
>>
>>
>>     It’s not clear to me that you need a *protocol* extension to signal
>> this?  Monolithically, a sender knows that it’s sending media, and can
>> choose its congestion control algorithm appropriately.
>>
>>
>>
>>     You definitely would need *API* signaling to indicate from the
>> application to the QUIC stack that media is being sent, and thus an
>> appropriate low-latency congestion controller should be chosen.  This is
>> absolutely relevant to the W3C API, and thus should probably be
>> communicated in the liaison statement response.
>>
>>
>>
>> Right.  And ideally, that API signaling would be powerful enough to
>> differentiate between different media and their requirements.  For example:
>>
>> -G711 audio has zero elasticity; if CC were to kick in, the realistic
>> choices are to ignore the CC, or terminate the session.  No middle ground.
>>
>> -Multi-resolution pre-coded video (think DASH) has some flexibility, but
>> bitrate adjustment can take many hundred milliseconds to seconds.
>>
>> -a software-based real-time video encoder can be built to have a lot of
>> flexibility, on very short notice—but, the application/user may not like
>> the encoder to exercise that flexibility.  For example, broadcast
>> contribution applications and their encoders would not want to start
>> skipping frames, go down with the resolution, or too far up with the QP,
>> even if that would make the CC happy.  Video conferencing, OTOH, could cope
>> with all of that, up to a certain pain-point.
>>
>
> I don't think that the webtransport api and the browser stack should have
> this information, it is completely up to the application to control what is
> the behaviour based on the current bw estimation.
>
> Moreover, I doubt that the webtransport stack could provide a valid bw
> estimation usable by the app at all.
>
> IMHO the bwe needs to be calculated at the js app level and just needs the
> quic cc not mess too much and if possible provide the reception time stats
> for the sent packets.
>
>
> Best regards
> Sergio
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>