Re: [AVT] New milestones approved - retransmission supression

[David R Oran <[e-mail]>]

+1
Roni's analysis makes sense to me.

On Dec 9, 2010, at 2:08 AM, Roni Even wrote:

> Hi Qin,
> I can agree that the NACK in RFC 4585 is a general negative acknowledge
> (feedback) message that reports that the receiver  did not get the reported
> packet and let the sender decide how to address the loss. On the other hand
> RFC 4588 adds a semantic to the NACK message saying  "The NACK feedback
> message format defined in the AVPF profile SHOULD be used by receivers to
> send retransmission requests." Which allows the receiver to prefer a
> specific behavior from the sender. When you look at the NACK message in the
> RTCP layer you cannot know what was meant by the message.
> 
> 
> I think that what the milestone is trying to address is both usages of NACK
> which are loss reporting and retransmission requests. For the NACK loss
> reporting use case there is text in section 3.5.2 of RFC 4585 which hints
> about suppression but does not provide enough information for all use cases
> discussed in the topology RFC 5117 for both usages. 
> 
> In this case the milestone should discuss both cases and recommend when to
> send NACK or a new message, so maybe we can leave the milestone as is,
> define the name of the new message to be third party loss report and explain
> the different use cases when NACK or the Third party loss report are used.
> 
> Roni Even
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Qin Wu
>> Sent: Thursday, December 09, 2010 3:31 AM
>> To: DRAGE, Keith (Keith); [e-mail]
>> Subject: Re: [AVT] New milestones approved
>> 
>> Hi, Chairs:
>> Taking into account recent discussions on the list, we have been
>> working on the revision of draft-wu-avt-retranmission-suppression-rtp,
>> going through document reviews and  will finalize soon probably in this
>> week.
>> As for approved milestones,  after some offline discussion with one
>> reviewer Colin, we think it is better or more appropriate to change the
>> second milestone text listed below from
>> "
>> May 2011  RTCP indication for retransmission suppression as proposed
>> standard
>> "
>> to
>> "
>> May 2011  RTCP Extension for Third-Party Loss Report as proposed
>> standard
>> "
>> 
>> Regards!
>> -Qin
>> ----- Original Message -----
>> From: "DRAGE, Keith (Keith)" <[e-mail]>
>> To: <[e-mail]>
>> Sent: Thursday, December 09, 2010 7:09 AM
>> Subject: [AVT] New milestones approved
>> 
>> 
>>> (As WG cochair)
>>> 
>>> AVT now has some new approved milestones as follows.
>>> 
>>> Feb 2011  Guidelines for the use of Variable Bit Rate Audio with
>> Secure RTP as informational (or possibly BCP)
>>> May 2011  RTCP indication for retransmission suppression as proposed
>> standard
>>> Oct 2011  RTP Header extension for client to mixer audio level
>> indication as proposed standard
>>> Oct 2011  RTP Header extension for mixer to client audio level
>> indication as proposed standard
>>> 
>>> Over the next few weeks we will progressively make calls for the
>> adoption of text to fulful these milestones, starting at the end of
>> next week (and taking account of the Christmas period).
>>> 
>>> This message therefore requests two things.
>>> 
>>> 1) Can the authors of the following drafts ensure that your text is
>> at the best status to make such a call. Please take into account recent
>> discussions and review your documents, and update them if necessary.
>>> 
>>> If you are planning a revision, then please do send a message to the
>> WG chairs, identifying potential timescales for that revision. (It is
>> so embarassing to make a call to adopt a particular version of the
>> document, and find it revised 3 hours later)
>>> 
>>> http://datatracker.ietf.org/doc/draft-perkins-avt-srtp-vbr-audio/
>>> http://datatracker.ietf.org/doc/draft-wu-avt-retransmission-
>> supression-rtp/
>>> http://datatracker.ietf.org/doc/draft-ivov-avt-slic/
>>> http://datatracker.ietf.org/doc/draft-lennox-avt-rtp-audio-level-
>> exthdr/
>>> 
>>> 2) If anybody has alternative ideas they wish to write up to fulfil
>> these work areas, then this is the time to do it.
>>> 
>>> If you are planning this, then a message to the WG chairs of your
>> intention is also appropriate (along with your envisaged timescales for
>> submission).
>>> 
>>> 
>>> 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
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt