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

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

Hi

Please see inline
/Ingemar

> -----Original Message-----
> From: Jonathan Lennox <[e-mail]>
> Sent: den 26 mars 2019 10:00
> To: Ingemar Johansson S <[e-mail]>
> Cc: IETF AVTCore WG <[e-mail]>; [e-mail]
> Subject: Re: [AVTCORE] Notes on RTP CC Feedback from the Hackathon
> 
> 
> 
> > On Mar 26, 2019, at 8:59 AM, Ingemar Johansson S
> <[e-mail]> 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.
[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
> >
> >
> >> 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
> >> ***********************************