Re: [AVT] Adoption of new milestones

["Van Caenegem, Tom (Tom)" <[e-mail]>]

Hi Qin,

See my comments below
(Tom)..
Regards.



-----Original Message-----
From: Qin Wu [mailto:[e-mail]]
Sent: vrijdag 19 november 2010 4:29
To: Van Caenegem, Tom (Tom); DRAGE, Keith (Keith); [e-mail]
Subject: Re: [AVT] Adoption of new milestones

Hi, Tom:
Thank you for feedback very early. :-)
I didn't say the sender/middlebox can not send feedback message to the upstream node like media source for some purpose,e.g., ask for retransmission of losted packet, but it is weird to ask the sender/middlebox send the same feedback message to upstream node and downstream receiver to ask for the lost packet at the same time . This cause scemantics confusion.



Tom: this is the definition of the NACK message in RFC 4585: "The Generic NACK is used to indicate the loss of one or more RTP packets".
So, if a entity declared itself to provide retransmissions, and it gets this NACK, it may send a corresponding retransmission as  response on receiving this NACK (RFC 4588). If an entity is "just" an RTP receiver for the considered SSRC and receives a NACK, it must act according to RFC 4585, which specifies how it should refrain from immediately sending a NACK, when it detected the same packet loss. There is no semantics confusion.



Feedback Indication message defined in draft-wu-avt-retransmission-suppression-rtp and receiver reports, Sender Report defined in RFC3550 and reciever summary  Information(RSI) packet defined in RFC5760 are all RTCP message. However Unlike receiver reports , and RSI packet, Feedback Indication message is one feedback message and more look like sender report. But it is confusing to mix RTCP AVPF transport layer Feedback messsage with Receiver report or any other kind of report.

As described in RFC4585
"
  Generic NACK feedback SHOULD NOT be used if the underlying transport
   protocol is capable of providing similar feedback information to *the
   sender* (as may be the case, e.g., with DCCP).

Tom: not sure what your message is here.. DCCP combining with multicast looks problematic.


 In many cases NACK is sent from media receiver at the downstream side to the media sender at the upstream side. e.g., In RAMS case, NACK is sent from RTP_Rx to the RBS to ask for Retransmission of lost packet. However you can not expect the RBS to send the NACK to the RTP_Rx to ask for Retransmission of lost packet.

Tom: as defined in RFC 4585, and explained above, a NACK is NOT about asking retransmission, it is about packet loss reporting.

Tom: in the RAMS case, the BRS/FT will most likely be decoupled from the DS. If you want the BRS/FT to advertise the observed packet loss to the RTP receivers reporting to this FT, how will you get that message to the RTP receivers? This is one of the issues that need to be solved/defined, and I have not seen this addressed in the draft...


becos the RTP_Rx is not sender from the RBS perspective. But if RBS ask for retransmission of lost packet from the media source, the RBS take the role of the receiver from the media source perspective. But It is confusing to look at RBS as Receiver from both Media source perspective and RTP_Rx perspective.


This had been discussed in the previous meeting and mailing list for many times. It is not just my personal view.
As for the other feedback message like Picture Loss Indication (PLI) and Slice Loss Indication (SLI), they are both sent from downstream decoder to the upstream encoder. But In the draft-wu-avt-retransmission-suppression-rtp,
we do need a RTCP Indication message sent from upstream sender to the downstream RTP_Rx.

As for the additional RTT issues, this issues had been discussed very eraly, please look at the following link to this discussion:
http://www.ietf.org/mail-archive/web/avt/current/msg13299.html

Tom: I know all this. I responded on your assertion that if the middle box sends a NACK to indicate suppression indication -iso a dedicated RTCP message-, this has additional RTT delay. This is incorrect if the packet loss took place upstream of the middle box.


As for the last point you mentioned, as I explained, RFC4585 just provide the receiver with one algorithm on how to schedule its own feedback when the receiver is the same group with other receivers. However when packet loss happens close to media source, all the recievers may send feedback almost at the same time concurrently, it does not make sense to ask all the recievers listen on this problem when all the reciever have already sent the feedback message out.

Tom: I agree, and again,  having the middle box sending a NACK to all receivers iso of the suppression indication will result in the same behaviour at the receivers. Unless you want a receiver behaviour different from the one defined in RFC 4585.

You may also look at the figure 1 and section 5 of RFC5968, you can see Sender Report in the downsream direction and Receiver Report  in the upstream direction construct the complete Feedback Loop.
But you can not expect to use one NACK message in both directions to construct the Feedback Loop.

Tom: do not agree: if a middelbox also acts as receiver in a multi party session, it sends its RTCP reports to all participants, resulting in FB suppression as per RFC 4585.

Hope this clarifies.


Tom: not really.....so where do we go from here? To me it would make sense to explain more in a generic way how feedback storms in multi-point RTP sessions (including SSM) can be prevented or mitigated  (see http://www.ietf.org/mail-archive/web/avt/current/msg13785.html ), see where it would make sense to have an explicit suppression indication rather than using NACK (or other FB message) for this, and -very important - also elaborate how the suppression indication/NACK is provided to the receivers (e.g. the RAMS topology). I suggest therefore to rename the draft as "feedback suppression in multi-point sessions", and address the items as per above.


Regards!
-Qin
----- Original Message -----
From: "Van Caenegem, Tom (Tom)" <[e-mail]>
To: "Qin Wu" <[e-mail]>; "DRAGE, Keith (Keith)" <[e-mail]>; <[e-mail]>
Sent: Thursday, November 18, 2010 10:33 PM
Subject: RE: [AVT] Adoption of new milestones


Hi Qin,

A server/sender that by itself detects packet loss (on its uplink), functions as an RTP receiver and hence can itself send a NACK, to which the other RTP receivers then react according to RFC 4585. This is the major point of divergence with the views expressed in your draft.

E.g. RFC 5760 states  (p13) :   "From an RTP perspective, the Distribution Source is an RTP receiver, generating its own Receiver Reports and sending them to the receiver group and to the Media Senders."

Also in RFC 5117 there is language that indicates a transport translator can act as a receiver (section 3.3): "A Translator normally does not use an SSRC of its own, and is not visible as an active participant in the session.  One exception can
   be conceived when a Translator acts as a quality monitor that sends
   RTCP reports and therefore is required to have an SSRC.  Another
   example is the case when a Translator is prepared to use RTCP
   feedback messages.  This may, for example, occur when it suffers
   packet loss of important video packets and wants to trigger repair by
   the media sender, by sending feedback messages.  To be able to do
   this it needs to have a unique SSRC."

So I do not agree when you say there is a "dedicated" receiver required and when you say there is additional RTT involved, when using NACKs as suppression indication.

I do not exactly get your point when you say " RFC4585 only solves how to reduce the RTCP traffic storm within the same group by using reciever suppression algorithm, however how to reduce upstream RTCP traffic beyond the group of recievers  when large number of feedbacks for lost packet are addressed to the same media source  and middlebox is not covered."

Can you elaborate on that, please?

Regards
Tom


-----Original Message-----
From: Qin Wu [mailto:[e-mail]]
Sent: woensdag 17 november 2010 7:14
To: Van Caenegem, Tom (Tom); DRAGE, Keith (Keith); [e-mail]
Subject: Re: [AVT] Adoption of new milestones

Hi,
Feedback Suppression algorithm specified in RFC4585 is just *receiver algorithm* about how the receiver tunes the timing of sending Feedback message to the sender to avoid currenncy of large number of  feedback *in the same group*.
the media source or middlebox can be in the different group as receivers. This alogorithm applies for all the existing feedback message and new feedback message.

draft-wu-avt-retransmission-suppression-rtp  focuses on specifying *mechanism* on how the sender or server(e.g., media source or middlebox)  informs  the receiver that packet loss is detected and sending feedback for packet loss should be held on right now in case of packet loss occuring close to the media sender or at the upstream of middlebox.
The mechanism needs *RTCP extension* and can be used to avoid large number of feedback addressed to *the same media source or middlebox at the upstream*.

The suppression indication mechanism specified in draft-wu-avt-retransmission-suppression-rtp does not need to rely on any other reciever reporting packet loss event.
the media souce or middlebox can detect pakcet loss by themselves and create new suppression messsages to the receivers.

Therefore RFC4585 and draft-wu-avt-retransmission-suppression-rtp address the different aspects or use cases of the problem.
Also Feedback Suppression Indication mechanism can be used with Feedback Suppression algorithm specified in RFC4585.

As regarding why the new RTCP message needs to be defined, there are many direct or indirect reasons based on my understanding and many discussion in the previous two IETF meeting:

1. RFC4585 only solves how to reduce the RTCP traffic storm within the same group by using reciever suppression algorithm,
   however how to reduce upstream RTCP traffic beyond the group of recievers  when large number of feedbacks for lost packet
   are addressed to the same media source  and middlebox is not covered.

2. The mechanism specified in draft-wu-avt-retransmission-suppression does not need to rely on
    any NACK from any other reciever to detect the packet loss, the middlebox or media source can detect packet
    loss by themselves  and inform the receiver the lost event as early as possible by sending the RTCP message to downstream.

3. Relying on NACK from any dedicated reciever to report loss packet may slow down suppression operation by introducing extra roundtrip
    between dedicated reciever and middlebox comparing with using middlebox to inform the receiver about suppression indication. Also
   NACK lack scemantics for supppression indication to the receiver.

4. NACK is sent from AVPF receiver to the upstream AVPF sender, e.g., in RAMS case, the RTP_Rx can issue retransmission requests via RTCP NACK
    messages sent as unicast feedback in the primary multicast RTP session to BRS for lost packet. in such case, RTP_Rx is reciever and BRS is Sender.
    however in many use cases of draft-wu-retransmission-suppression-rtp or RTP topologies defined in RFC5117, we also need one message sent from
   upstream sender to the downstream reciever  which can not be satisfied using NACK. Therefore  rough consesus shows that it is better to define the
   new suppression messsage which is created by media source or middlebox itself and sent  to the downstream receiver.

5. RFC4585 allows receiver receive and process different Feedback message including any new feedback message like the
    new suppression message defined in draft-wu-avt-retransmission-suppression-rtp.

Hope this clarifies.

Regards!
-Qin
----- Original Message -----
From: "Van Caenegem, Tom (Tom)" <[e-mail]>
To: "DRAGE, Keith (Keith)" <[e-mail]>; <[e-mail]>
Sent: Tuesday, November 16, 2010 7:02 PM
Subject: Re: [AVT] Adoption of new milestones


> Hi,
>
> On the item: "RTCP indication for retransmission suppression as proposed standard"
>
> As expressed in various emails I am not convinced there is need for such a new draft/mile stone, as RFC 4585 has addressed the problem IMO. The authors should first clarify what use cases are addressed that are not covered by RFC 4585, and linked to that, why a new RTCP message needs to be defined.
>
> (Note that the name is wrong: it is actually about feedback suppression, not retransmission suppression!!)
> Tom
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of DRAGE, Keith (Keith)
> Sent: vrijdag 12 november 2010 0:48
> To: [e-mail]
> Subject: [AVT] Adoption of new milestones
>
> (As AVT WG cochair)
>
> We are looking to see if we should adopt a number of new milestones in AVT. This is the adoption of the milestone, not the selection and adoption of an particular draft to fulfil that milestone (that comes later).
>
> There are four potential new milestones:
>
> - RTP Header extension for mixer to client audio level indication as proposed standard
> - RTP Header extension for client to mixer audio level indication as proposed standard
> - RTCP indication for retransmission suppression as proposed standard
> - Guidelines for the use of Variable Bit Rate Audio with Secure RTP as informational (or possibly BCP)
>
> We took a brief show of hands in the meeting room in Beijing to see that there was a community that would support the work, and to see if others thought that these either should not be performed or interfered with the existing workload. So if you wish to add your opinion to these please:
>
> For each of the above proposals indicate to the chairs at [e-mail] (or to the list if you wish) if:
>
> A) you are prepared to support the work in AVT by reviews, comments proposed text or other appropriate means.
>
> B) you believe creation of this milestone is either inappropriate or will have a detrimental impact on resources available to other work in AVT.
>
> If you already represented your view in the meeting room in Beijing (or by Jabber), or do not wish to indicate eother A) or B), you do not need to respond.
>
> There are candidate author drafts for all of these milestones if you wish to review the potential work.
>
> https://datatracker.ietf.org/doc/draft-ivov-avt-slic/
> https://datatracker.ietf.org/doc/draft-lennox-avt-rtp-audio-level-exthdr/
> https://datatracker.ietf.org/doc/draft-wu-avt-retransmission-supression-rtp/
> https://datatracker.ietf.org/doc/draft-perkins-avt-srtp-vbr-audio/
>
> regards
>
> Keith
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt