Subject: Re: [rmcat] [AVTCORE] Notes on RTP CC Feedback from the Hackathon

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 26 Mar 2019 07:59:21 +0000

Hi

As regards to the MTU limitation. 
The SCReAM implementation implements a limit when the RTCP FB packets are
generated. If that limit is reached then any additional RTCP FB messages
that wait for transmission have to wait until the next RTCP feedback
transmission. 
https://github.com/EricssonResearch/scream/blob/master/code/ScreamRx.cpp#L27
9 
In addition there is a limit on how many RTP packets that can be reported
for a given stream (currently 64 RTP packets). This gives a potential risk
that holes in the RTCP feedback occurs, for that reason it is necessary to
enforce transmission of RTCP FB before 64 RTP packets are received, in the
code an extra check makes sure that RTCP feedback is transmitted when > 64/4
= 16 RTP packets are received, this gives an extra margin to avoid that lost
RTCP feedback triggers the packet loss detection.
https://github.com/EricssonResearch/scream/blob/master/code/ScreamRx.cpp#L34

The SCReAM implementation relies _only_ on the RTP CC feedback

Quote : "There should be guidance on how CCFB?s SSRC-and-RTP sequence
feedback
format can be mapped into a single sequence number space, of the sort that
many congestion control algorithms will want as input."
I don't understand this. Do you mean that if you have two encoders that
produce RTP packets then they should get RTP sequence numbers from a single
monotonically increasing sequence number function ? 
I don't see that this is necessary. At least in SCReAM, each stream (source)
have its own list of transmitted packets with their respective RTP sequence
numbers, this list is matched against the RTCP feedback.
But perhaps I misunderstood ?

/Ingemar

> Date: Mon, 25 Mar 2019 12:19:56 +0100
> From: Jonathan Lennox <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>, [email-masked]
> Subject: [AVTCORE] Notes on RTP CC Feedback from the Hackathon
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset=utf-8
> 
> Sergio Mena, Nils Olhmeier, and I got RTP CC Feedback interoperating at
the
> IETF Hackathon this weekend.
> 
> Sergio (with help from Nils) got it working in Firefox, driving
libwebrtc?s GCC; I
> had it working in our proprietary codebase with our proprietary congestion
> control algorithm.  We had media flow between my computer at the Hackathon
> and Sergio?s in Switzerland, with both sides achieving what seemed to be
> reasonable bitrates for the network. (We didn?t do careful study of the
results in
> the time we had available, though.)
> 
> Some issues we noticed:
> 
> * In BUNDLE, it?s not clear whether it should be legitimate to negotiate
CCFB on
> some but not all of a group of bundled media descriptions.  I.e., what
should the
> bundle category of a=rtcp-fb:* ack ccfb be?
> 
> * SDP ABNF syntax is fairly arcane, so it wasn?t immediately obvious to
> everyone that the signaling was indeed supposed to be ?a=rtcp-fb:* ack
ccfb?.
> An example would probably be helpful.
> 
> * Offerers will often want to offer a variety of congestion control
feedback
> mechanisms for maximum interoperability, but bad things can happen if you
try
> to use more than one at once.  Thus, answerers should answer with only one
> option, and if that doesn?t happen (i.e. if an answer contains more than
one
> option) an endpoint should either pick just one it likes best, or
complain/fail.
> 
> * CCFB, unlike most RTCP messages, isn?t intrinsically bounded in size.
When
> bandwidths are very asymmetric, you can end up with more feedback reports
> than will fit in an MTU.  Implementations should make sure to generate
multiple
> feedback packets in this case.
> 
> * There should be guidance on how CCFB?s SSRC-and-RTP sequence feedback
> format can be mapped into a single sequence number space, of the sort that
> many congestion control algorithms will want as input.
> 
> * Congestion algorithms need to understand what to do in response to lost
> feedback messages.  It?s generally a bad thing to treat them as media
packet
> losses, but it?s also bad to treat them as though the packets were
received
> perfectly.
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> ------------------------------
> 
> End of avt Digest, Vol 178, Issue 4
> ***********************************

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 26 Mar 2019 10:00:19 +0100

> On Mar 26, 2019, at 8:59 AM, Ingemar Johansson S <[email-masked]> wrote:
> 

No, that’s not what I’m saying.  RTP sequence numbers should behave as normal.

The question here is about maintaining *local* data (internal to the sender’s data structures) remembering the a total order of the packets sent across all SSRCs, for congestion control algorithms that want to treat data sent as a single aggregate, rather than treating SSRCs independently.

The suggestion would be to provide some non-normative implementation guidance on how best to maintain this, efficiently.

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 26 Mar 2019 09:15:02 +0000

Hi

Please see inline
/Ingemar

> -----Original Message-----
> Sent: den 26 mars 2019 10:00
> To: Ingemar Johansson S <[email-masked]>
> Cc: IETF AVTCore WG <[email-masked]>; [email-masked]
> Subject: Re: [AVTCORE] Notes on RTP CC Feedback from the Hackathon
> 
> 
> 
> > On Mar 26, 2019, at 8:59 AM, Ingemar Johansson S
> <[email-masked]> wrote:
> >
> > feedback format can be mapped into a single sequence number space, of
> > the sort that many congestion control algorithms will want as input."
> > I don't understand this. Do you mean that if you have two encoders
> > that produce RTP packets then they should get RTP sequence numbers
> > from a single monotonically increasing sequence number function ?
> > I don't see that this is necessary. At least in SCReAM, each stream
> > (source) have its own list of transmitted packets with their
> > respective RTP sequence numbers, this list is matched against the RTCP
> feedback.
[IJ] OK, thanks for the clarification

> 
> The question here is about maintaining *local* data (internal to the sender’s
> data structures) remembering the a total order of the packets sent across all
> SSRCs, for congestion control algorithms that want to treat data sent as a single
> aggregate, rather than treating SSRCs independently.
[IJ] Ok, I guess that should be doable if you keep a list of transmitted packets and the time when they have been transmitted, already available in the SCReAM code but it would take some sorting to get the transmission order, not sure though what one can use this piece of information for ?

> 
> The suggestion would be to provide some non-normative implementation
> guidance on how best to maintain this, efficiently.
> 
> >
> > /Ingemar
> >
> >
> >> had it working in our proprietary codebase with our proprietary
> >> congestion control algorithm.  We had media flow between my computer
> >> at the Hackathon and Sergio?s in Switzerland, with both sides
> >> achieving what seemed to be reasonable bitrates for the network. (We
> >> didn?t do careful study of the
> > results in
> >> * SDP ABNF syntax is fairly arcane, so it wasn?t immediately obvious
> >> to everyone that the signaling was indeed supposed to be ?a=rtcp-fb:*
> >> ack
> > ccfb?.
> >> to use more than one at once.  Thus, answerers should answer with
> >> only one option, and if that doesn?t happen (i.e. if an answer
> >> contains more than
> > one
> >> bandwidths are very asymmetric, you can end up with more feedback
> >> reports than will fit in an MTU.  Implementations should make sure to
> >> generate
> > multiple
> >> * There should be guidance on how CCFB?s SSRC-and-RTP sequence
> >> feedback format can be mapped into a single sequence number space, of
> >> the sort that many congestion control algorithms will want as input.
> >>
> >> * Congestion algorithms need to understand what to do in response to
> >> lost feedback messages.  It?s generally a bad thing to treat them as
> >> media
> > packet
> >> Audio/Video Transport Core Maintenance [email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 26 Mar 2019 10:29:10 +0100

> On Mar 26, 2019, at 10:15 AM, Ingemar Johansson S <[email-masked]> wrote:
> 
> 
>> 

If SCReAM doesn’t need this, that’s fine; it doesn’t need to maintain it.

Other algorithms may need it, however.  In particular, GCC wants packet sequence numbers (or at least the GCC API in libwebrtc does), which is where we ran into the issue.

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 26 Mar 2019 09:32:05 +0000

OK, then I get it, thanks.

/Ingemar

> Sent: den 26 mars 2019 10:29
> > On Mar 26, 2019, at 10:15 AM, Ingemar Johansson S
> >> The question here is about maintaining *local* data (internal to the
> >> sender’s data structures) remembering the a total order of the
> >> packets sent across all SSRCs, for congestion control algorithms that
> >> want to treat data sent as a single aggregate, rather than treating SSRCs
> independently.
> > [IJ] Ok, I guess that should be doable if you keep a list of transmitted packets
> and the time when they have been transmitted, already available in the SCReAM
> code but it would take some sorting to get the transmission order, not sure
> though what one can use this piece of information for ?
> 
> Other algorithms may need it, however.  In particular, GCC wants packet
> sequence numbers (or at least the GCC API in libwebrtc does), which is where we
> ran into the issue.