Re: [tsvwg] Comments on draft-kaippallimalil-tsvwg-media-hdr-wireless-04

[Ingemar Johansson S <[e-mail]>]

Hi
OK, then I believe I understand the scope better, thanks!

/Ingemar

From: Kaippallimalil John <[e-mail]>
Sent: Tuesday, 19 March 2024 23:20
To: Ingemar Johansson S <[e-mail]>; [e-mail]
Subject: RE: Comments on draft-kaippallimalil-tsvwg-media-hdr-wireless-04

Hi Ingemar,

Thank you for the comments and thorough analysis.
The attempt was to use that text to motivate the need for metadata and in the process of generalizing across sub-6GHz, mmWave (with dramatic shifts), Wi-fi and the text is not clear now.
For the motivation part, we’ll revise the text to keep it accurate and minimal.

On the solution side of the need to expose stream level information, we have added requirements/metadata proposed to expose either “frame” level information, or “stream” level information (section 3.2).
This should cover the scenario you have outlined below from the point of the application providing this information.
We’ll revise to include some of the high level concepts below but also stay away from too many details since the aim of the metadata is to provide “information” that a traffic shaper /queuing can act on to put in different DRBs, etc.

BR,
John


From: Ingemar Johansson S <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, March 19, 2024 5:18 AM
To: [e-mail]<mailto:[e-mail]>; Kaippallimalil John <[e-mail]<mailto:[e-mail]>>
Cc: Ingemar Johansson S <[e-mail]<mailto:[e-mail]>>
Subject: Comments on draft-kaippallimalil-tsvwg-media-hdr-wireless-04

Hi John + others


Thanks for bringing up draft-kaippallimalil-tsvwg-media-hdr-wireless-04 today.

As it goes into 3GPP networks and their function I though that I should comment on the parts that are relevant from that perspective.

Section 3.1 brings up "Feedback provided by ECN/L4S to the server (UDP sender) is not fast enough to adjust the sending rate when available wireless capacity  changes significantly in very short periods of time (~ 1   millisecond)."

I am not sure if you refer to fast fading or dramatic drops in throughput.

L4S actually handles fast fading quite well (and slow fading). You can see an example on page 18 in https://github.com/EricssonResearch/scream/blob/master/L4S-Results.pdf?raw=true
You can however see some delay jitter, that is due to a combo of fast fading as well as empty UE (modem) buffer which necessitates transmission of a sheduling request to transmit data in uplink (this can be mitigated with pre-scheduling or configured grant scheduling). It is not reasonable to discard packets due to this delay jitter however, as the frequent discard would require additional FEC overhead to give the applications an acceptable throughput.

Then it is the question of dramatic drops in throughput. Here there can be cases where it goes so fast that the rate adaptation is not fast enough. And then for instance video frames can become too late for the decoding. It is however not for certain that it is beneficial to drop them in the network as the video can still be decoded based on the late frame and the decoder state is then still valid, discarded video frames are quite likely to require an decoder refresh to get good video again.
We can imagive that we have both audio and video in the same DRB (data radio bearer) and the potential problem is then that large video frames would delay the more delay sensitive audio frames. To me the obvious method would be to have audio and video in separate DRBs and give the audio DRB a higher priority with the QoS tools that are already available. For instance with VoLTE and VoNR, dedicated DRBs are used for voice. Thus it is not necessary to prioritize and reorder packets in a DRB queue. Is this something that you consider in your work?.

Note also that L4S is merely a signal of congestion, how to determine when to set congestion experienced is up to vendor implementation. The most simple approach is to base congestion marking on measured queue delay but there may be other methods that can me more efficient in light of dramatic drops in throughput. My impression is that we have not explored the potential with L4S well enough to draw the conclusion that ECN and L4S is not fast enough. L4S is just recently out from the baking oven in 3GPP and first product relase from Ericsson is Q2 this year. We are still at the very beginning of this journey.



Regards

/Ingemar
=================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson AB
GFTL ER Networks RNS Protocol & E2E Perf
Labratoriegränd 11
977 53, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com<http://www.ericsson.com/>

         The right to be ridiculous is
              something I hold dear...
                              U2
=================================