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

> On Mar 26, 2019, at 8:59 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> 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 ?

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.

> 
> /Ingemar
> 
> 
>> Date: Mon, 25 Mar 2019 12:19:56 +0100
>> From: Jonathan Lennox <jonathan@vidyo.com>
>> To: "rmcat@ietf.org WG" <rmcat@ietf.org>, avtcore@ietf.org
>> Subject: [AVTCORE] Notes on RTP CC Feedback from the Hackathon
>> Message-ID: <91FCCD42-F4DB-45B2-9673-828F327743F8@vidyo.com>
>> 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
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>> 
>> 
>> ------------------------------
>> 
>> End of avt Digest, Vol 178, Issue 4
>> ***********************************