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

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

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 <[e-mail]>
> To: "[e-mail] WG" <[e-mail]>, [e-mail]
> Subject: [AVTCORE] Notes on RTP CC Feedback from the Hackathon
> Message-ID: <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> ------------------------------
> 
> End of avt Digest, Vol 178, Issue 4
> ***********************************