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

[Bob Briscoe <[e-mail]>]

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).

> 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.


> 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.

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]
>
> www.ericsson.com <http://www.ericsson.com/>
>
> Talk about a dream, try to make it real
>
> Bruce Springsteen
>
> =================================
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/