Re: [AVTCORE] Question on draft-ietf-avtcore-cc-feedback-message-02

[Zaheduzzaman Sarker <[e-mail]>]

Hi Ingemar,

I admit that the text could have been much clearer, but still, I read is as ATO=RTS-RTP_TS, where RTS is the time of the generation of the report and RTP_TS is recorded some time before RTS.

The offset is really from the time RTCP report is generated and we expect that the report generation time is very close to report sent time.

And thanks for implementing the new feedback format in SCReAM code ☺, would be very interested in your implementation and usage experience.

BR

Zahed

On 2018-08-22, 19:00, "Ingemar Johansson S" <[e-mail]<mailto:[e-mail]>> wrote:

Hi
Time to read up on
https://tools.ietf.org/pdf/draft-ietf-avtcore-cc-feedback-message-02.pdf
with the intention to update the SCReAM code (https://github.com/EricssonResearch/scream ).


The question :

The ATO confuses me a bit. Quote

“It is measured as an offset from the time
      at which the RTCP congestion control feedback report packet is
      sent.  The arrival time offset is calculated by subtracting the
      reception time of the RTP packet denoted by this 16 bit packet
      metric block from the Report Timestamp (RTS) field of the RTCP
      congestion control feedback report packet in which the packet
      metric report block is contained.
”
I try to read this sentence over and over again, but always come to the conclusion that the ATO values will become negative.
I assume here that the RTCP RTS (Report Time Stamp) is picked when the RTCP report is generated. The RTP packets are received prior to this, this means then that
ATO = RTP_TS-RTS <= 0. Is this true or am I lost in translation ?.


The comment :
I have experimented with SCReAM (RFC8298) for a while now and it seems that it operates well with feedback every 10-16 packets (give or take). This holds for bitrates from <1Mbps up to 100Mbps. In practice this means that at very high bitrates, an RTCP packet will be send as often as every 2ms or so. With 16 packets reported in an RTCP the resulting size is 2*16+8+8 = 48 octets, this should be manageable from an RTCP BW perspective. The current proprietary format that is used only have one timestamp that represents the last received RTP packet. Once the new format is implemented, I will update the SCReAM code to take advantage of the per packet time stamp. I don’t expect miracles but it should at least not become worse.

/Ingemar

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

Ericsson Research
Network Protocols & E2E Performance
Labratoriegränd 11
971 28, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com

         Between the wish and the thing
               the world lies waiting.
                 Cormac McCarthy
==================================