Re: [AVT] New milestones approved - retransmission supression

[Roni Even <[e-mail]>]

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