Subject: [AVT] New milestones approved

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Dec 2010 00:09:22 +0100

(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

---

From: Qin Wu <[email-masked]>
Date: Thu, 09 Dec 2010 09:31:29 +0800

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)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 09, 2010 7:09 AM
Subject: [AVT] New milestones approved

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 8 Dec 2010 17:37:22 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Wednesday, December 08, 2010 8:31 PM
> To: DRAGE, Keith (Keith); [email-masked]
> 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
> "

+1. Looking forward to the simplified and more to-the-point text.

-acbegen

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Dec 2010 02:38:21 +0100

Thank you for your message.

It is probably best to deal with the change in milestone name after or during the adoption of text. That should not affect whether you want to change the title or indeed the contents of your proposal.

I know Tom van Caenegem was still not happy with your current version. While that is not a show stopper, I would appreciate if you could do some offline work to come to an acceptable compromise with him, that takes into account his last comments to the list on this subject (or indeed persuades him otherwise).

My current thoughts are to do the text adoption calls on this partly sequentially to completion date, ie. VBR first, then this milestone, then the audio level ones. That will be affected by the authors indications on the availability of drafts, but gives you at least an extra week for those discussions.

regards

Keith 

> From: Qin Wu [mailto:[email-masked]] 
> Sent: Thursday, December 09, 2010 1:31 AM
> 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
> > Feb 2011  Guidelines for the use of Variable Bit Rate Audio 
> with Secure RTP as informational (or possibly BCP)  
> > 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).
> > 
> > 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)
> > 
> > 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

---

From: Roni Even <[email-masked]>
Date: Thu, 09 Dec 2010 09:08:50 +0200

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

> Sent: Thursday, December 09, 2010 3:31 AM
> 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
> "
> > Feb 2011  Guidelines for the use of Variable Bit Rate Audio with
> Secure RTP as informational (or possibly BCP)
> > 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).
> >
> > 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)
> >
> > 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

---

From: Qin Wu <[email-masked]>
Date: Thu, 09 Dec 2010 16:26:33 +0800

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

> RTCP layer you cannot know what was meant by the message.

[Qin]: Right.
 
> discussed in the topology RFC 5117 for both usages. 

[Qin]: Good point.

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

---

From: David R Oran <[email-masked]>
Date: Thu, 9 Dec 2010 12:33:11 -0500

+1
Roni's analysis makes sense to me.