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

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 22 Aug 2018 17:00:10 +0000

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 +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Aug 2018 10:25:19 +0200

> On 22 Aug 2018, at 19:00, Ingemar Johansson S <[email-masked]> wrote:
> 
> Hi 
> Time to read up on 
> https://tools.ietf.org/pdf/draft-ietf-avtcore-cc-feedback-message-02.pdf <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 <https://github.com/EricssonResearch/scream> ).
>  
> The question : 
> “It is measured as an offset from the time
> ”

It’s an offset before the report. That is, if the ATO field has value 1024, the RTP packet arrived 1 second before the report was prepared. Suggestions for clearer wording appreciated.

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

Thanks!
Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 23 Aug 2018 08:44:06 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote:

Hi
Time to read up on

The question :

The comment :

/Ingemar

Ericsson Research

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 24 Aug 2018 06:05:21 +0000

OK, thanks for answers Colin and Zahed, that clarifies things for me 😊

One last question for now. Each RTP packet is represented by 16bits (L,ECN and ATO field). I assume that the 16 bit word should be written in network byte order ?

/Ingemar

From: Colin Perkins <[email-masked]>
Sent: den 23 augusti 2018 10:25
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] Question on draft-ietf-avtcore-cc-feedback-message-02

On 22 Aug 2018, at 19:00, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:

Hi
Time to read up on

The question :

The comment :

Thanks!
Colin

--
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Aug 2018 17:18:46 +0100

> On 24 Aug 2018, at 07:05, Ingemar Johansson S <[email-masked]> wrote:
> 

Yes.

Cheers,
Colin