Re: [AVT] New milestones approved - retransmission supression

[Qin Wu <[e-mail]>]

Hi,
----- Original Message ----- 
From: "Roni Even" <[e-mail]>
To: "'Qin Wu'" <[e-mail]>; "'DRAGE, Keith (Keith)'" <[e-mail]>; <[e-mail]>
Sent: Thursday, December 09, 2010 3:08 PM
Subject: RE: [AVT] New milestones approved - retransmission supression


> 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.

[Qin]: Right.
 
> 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. 

[Qin]: Good point.

> 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.

[Qin]: Yes, this is what we are doing in the new version.
 One typical example to clarify when to send a new message or NACK is SSM use case, 
In the summary distribution model, the third party observing the loss cannot directly inform 
the other receivers, and so a third-party loss report is needed, and a NACK cannot be used. 

In the simple reflection model, NACKs from the receiver observing the loss will be reflected 
to the other receivers, and there's no need for the third-party loss report.

> 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
>