Re: [tsvwg] Comments on draft-ietf-tsvwg-l4s-arch-07

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

Hi Bob

Please see inline tagged [IJ]

 

From: Bob Briscoe <[e-mail]> 
Sent: den 2 november 2020 23:10
To: Ingemar Johansson S <[e-mail]>
Cc: De Schepper, Koen (Koen) <[e-mail]>; Greg White <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Comments on draft-ietf-tsvwg-l4s-arch-07

 

Ingemar,

On 02/11/2020 10:39, Ingemar Johansson S wrote:

Hi

 

I have read through  draft-ietf-tsvwg-l4s-arch-07 and have a few comments

 

Section 4 page 11 on Host mechanisms : RFC6679 is listed for RTP, it is however good to add also  
https://tools.ietf.org/wg/avtcore/draft-ietf-avtcore-cc-feedback-message/ , this feedback format is used with SCReAM. cc-feedback-message is BTW listed in the L4S-ID draft.


Feedback protocols are discussed in the bullet below the one you are looking at. I think RTP is still the right thing to reference to describe the main protocol (that has things attached to it like congestion controls, feedback protocols, etc).

Nonetheless, you are right if we're talking about the following bullet, where it says RTCP is sufficient for L4S feedback. That was obviously written there a long time ago, and it needs to be updated to recommend using avtcore-cc-feedback-message.

Assuming you confirm I'm correct, I'll do that (before tonight's deadline, if you get back to me soon enough).
[IJ] Guess I was a bit late, but no big deal, this is jus a minor. I understand now that bullet b refers to the negotiation of the ECT(1) feedback. I believe though that a reference to https://tools.ietf.org/wg/avtcore/draft-ietf-avtcore-cc-feedback-message/ is sufficient as it itself rerfers to RFC66679 on how to negotiate ECN.



 

Section 6.2 :
+ One key benefit that I see with L4S is that it reduces delay jitter and this in turn makes it possible to tune down the dejjitterbuffers on the video streaming client side. The end result should be a better interactive experience for the end users.


Added. Thx



 

+ Another one, that may not be useful. SCReAM implement a transmission buffer on the sending side. This prevents that traffic bloats the network in case of a fast reduction in link throughput. In addition the transmission buffer can be discarded and the video coder can be requested to create a new key frame. This happens occasionally in the experiments with the RC cars that we run because the video coders in the NVIDIA Jetson Nanos are a bit slow to react to reduced target rate. This mechanism should be improved with addition of L4S support as we can then reduce the time that the video playout freezes as the queue buildup in the network is limited.


I'm not quite sure about this. 
* If there is a certain standing queue in the network, at a sudden reduction in capacity, the network queue will grow by a certain amount. 
* If the standing queue is less because of L4S, if there is the same sudden reduction in capacity, the queue will grow by the same amount. 
In both cases, to get the network queue back to where it was, the sender would have to dump the same amount from its send buffer.
So the send buffer can't be any smaller, just because the network queue is smaller.

What am I misunderstanding?

I can see you could reduce the send buffer if you used a virtual queue in the network to keep some spare headroom. But without any headroom, I don't get what you mean.

[IJ] I agree to some degree. I was more referring to the case where L4S marking is done based on actual (low) queue buildup for instance on the PDCP or RLC layer in a 5G radio base station. This was simulated in the master thesis by Davide Brunello. What we have seen is that with L4S marking and the use of off the shelf video encoders that produce frames that vary in size, the nominal bitrate becomes pushed down a bit to accommodate enough headroom to ensure transmission of the largest frames without large queue buildup in the network. The additional headroom often (but not always) gives less data in flight than the case when L4S is not enabled and therefore a reduced queue build up when link throughput drops. All this can of course be claimed to be specific to how SCReAM behaves when it runs with input from video encoders. Perhaps it also becomes too complex to explain in a comprehensible way. And, true , with a virtual queue the story becomes different but it becomes hard to rate control a media stream over a virtual queue without any form of network feedback.
I attached two graphs for the case that throughput drops from 40 down to 20Mbps in 0.3s (simple bottleneck, no 5G), to illustrate this case. I have set the queue delay target quite low in this case (10ms) to give at least a somewhat fair comparions, in reality this is not realistic as SCReAM would false trigger on scheduling jitter, process jitter, clock drift and what not. In any case it should show that L4S for this case gives a lower delay spike when L4S is enabled in the bottleneck.

Not sure that this is possible to follow … 

 

 

 







 

Nits : 
Section 8.1 Possible grammar… not sure “as best efforts traffic”, always thought it should be “as best effort traffic” ?. But then I am not a professor in the English language 😐


I usually say best efforts. Not sure whether it's any more correct than best effort. I just looked it up. It seems to have come from contract law. And usually it's written best efforts, but sometimes best effort. I'll leave it.

[IJ] OK 😊



Thanks for the review (again).


Bob




 

/Ingemar

================================

Ingemar Johansson  M.Sc. 

Master Researcher

 

Ericsson Research

RESEARCHER

GFTL ER NAP NCM Netw Proto & 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/> 

 

Talk about a dream, try to make it real

                  Bruce Springsteen

=================================

 





-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/ <https://protect2.fireeye.com/v1/url?k=00a2330a-5f390a49-00a27391-861fcb972bfc-d186ea0fb30cda50&q=1&e=5e345298-09e4-44b1-ad7b-e7973feacef2&u=http%3A%2F%2Fbobbriscoe.net%2F>