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:sunseawq@huawei.com] 
Sent: woensdag 17 november 2010 7:14
To: Van Caenegem, Tom (Tom); DRAGE, Keith (Keith); avt@ietf.org
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)" <tom.van_caenegem@alcatel-lucent.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>; <avt@ietf.org>
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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
> Sent: vrijdag 12 november 2010 0:48
> To: avt@ietf.org
> 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 avt-chairs@tools.ietf.org (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
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt