Subject: [AVT] WGLC for draft-ietf-avt-rapid-acquisition-for-rtp-09

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 5 May 2010 12:02:28 +0200

(As WG cochair)

This is to announce a WGLC for draft-ietf-avt-rapid-acquisition-for-rtp-09 (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to progress as proposed standard.

Please review and comment on the document by close of business Wednesday, 26th May 2010, i.e. this is a three week WGLC. We have given you an extra week as there is some substance to this document.

This is intended to be your final chance to review this document before the document is submitted to the IESG for publication, so please take this chance to make all the points you need to make. That includes editorial points as well as technical ones.

The WG chairs are aware that there are a number of references that are currently progressing behind this document. The WG chairs believe this lag will only become an issue at the final step for publication as an RFC, i.e. the ongoing discussion of those referenced documents should not affect the ability to review and progress this document. If you have another opinion, then please make that opinion known so it can be discussed and appropriately resolved.

Ideally please progress all comments to the avt mailing list.

regards

Keith

---

From: Roni Even <[email-masked]>
Date: Sun, 16 May 2010 12:20:11 +0300

Hi,
I reviewed the document and it looks good.
I have some nits.

1. In section 6.1 second paragraph "and carry the Reference Information" I
think it will be more precise to say " and carry Reference Information"
since it does not carry all the reference information.

2. In figure 3 you have at the end "unicast RTCP reports (for unicast
session)" but this flow is shown after RAMS-T. I assume that if BYE was not
sent they may exist but I think you meat for primary multicast session.

3. In section 6.2 in step 5 updated request I was wondering if the update
request need to include all the multicast primary streams as in the initial
request or can it just include the stream that needs an update. 

4. In section 6.2 step 9 terminate request in the second paragraph " it
cannot use RAMS-T message(s) and thus MUST send an RTCP BYE  message in the
unicast burst RTP session to terminate the request". I think that for the
BYE you also need to know the SSRC of the stream.

5. In section 7.2 on Max receive bitrate " that the RTP receiver can process
the aggregation of the unicast burst(s)  " I think that some words are
missing before "the aggregation"

Roni Even
As individual

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: Wednesday, May 05, 2010 1:02 PM
> To: [email-masked]
> Subject: [AVT] WGLC for draft-ietf-avt-rapid-acquisition-for-rtp-09
> 
> (As WG cochair)
> 
> This is to announce a WGLC for draft-ietf-avt-rapid-acquisition-for-
> rtp-09 (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to
> progress as proposed standard.
> 
> Please review and comment on the document by close of business
> Wednesday, 26th May 2010, i.e. this is a three week WGLC. We have given
> you an extra week as there is some substance to this document.
> 
> This is intended to be your final chance to review this document before
> the document is submitted to the IESG for publication, so please take
> this chance to make all the points you need to make. That includes
> editorial points as well as technical ones.
> 
> The WG chairs are aware that there are a number of references that are
> currently progressing behind this document. The WG chairs believe this
> lag will only become an issue at the final step for publication as an
> RFC, i.e. the ongoing discussion of those referenced documents should
> not affect the ability to review and progress this document. If you
> have another opinion, then please make that opinion known so it can be
> discussed and appropriately resolved.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 16 May 2010 05:04:01 -0700

Thanks.

> since it does not carry all the reference information.

OK.
 
> sent they may exist but I think you meat for primary multicast session.

They are for the unicast session. And you are right, since there is no BYE here, they may exist here.
 
> request or can it just include the stream that needs an update.

Good question. The general rule is to send the updated info only. However, there is nothing wrong to include the unchanged info, either. 
 
> BYE you also need to know the SSRC of the stream.

Yeah, but I believe at least upon receiving a BYE for the unicast session, the server will know what to do. I don't see any better alternative here. If there is a better alternative, let me know.
 
> missing before "the aggregation"

Do you rather prefer:
      Max Receive Bitrate (64 bits):  Optional TLV element that denotes
      the maximum bitrate (in bits per second) at which the RTP receiver can
      process the aggregation of the unicast burst(s) and ...

Thanks,
-acbegen

---

From: Roni Even <[email-masked]>
Date: Sun, 16 May 2010 17:38:07 +0300

Hi Ali,
Inline

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Sunday, May 16, 2010 3:04 PM
> To: Roni Even; [email-masked]
> Subject: RE: [AVT] WGLC for draft-ietf-avt-rapid-acquisition-for-rtp-09
> - comments
> 
> Thanks.
> 
> > Hi,
> Good question. The general rule is to send the updated info only.
> However, there is nothing wrong to include the unchanged info, either.

Maybe you can add clarfication

> Yeah, but I believe at least upon receiving a BYE for the unicast
> session, the server will know what to do. I don't see any better
> alternative here. If there is a better alternative, let me know.

The server may not know this SSRC and so will not remove it RFC 3550 section
6.3.4.  I think that if the RTP_Rx stop sending RTCP messages the session
will time out. 
The server can know that the RTP_Rx joined the multicast group based on RTCP
reports sent to the FT.

>       process the aggregation of the unicast burst(s) and ...

Looks better.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 16 May 2010 10:12:42 -0700

We are in agreement in other points. Inline.

> 6.3.4.  I think that if the RTP_Rx stop sending RTCP messages the session

Sure, but there is no harm in sending the BYE IMO since it provides a graceful termination. The only case the server will not the SSRC is when the server has not received anything at all and has not started the unicast session in the first place. A BYE will not hurt as the server will just discard it.

> The server can know that the RTP_Rx joined the multicast group based on RTCP

Sure, but until the first report, NACK, or whatever is sent to the FT, it won't know. So, I suggest we keep the BYE.

Thanks,
-acbegen

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 20 May 2010 14:50:30 +0200

(As WG cochair)

A reminder of the WGLC on the above document, which is currently in progress and is programmed to end on 26th May.

Please review this document. There has been so far a disappointing level of indication of people having read this document. Even partial reviews are useful. 

If you have read it and you think it is OK then please send the WG chairs a mail saying so.

regards

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: Wednesday, May 05, 2010 11:02 AM
> To: [email-masked]
> This is to announce a WGLC for 
> draft-ietf-avt-rapid-acquisition-for-rtp-09 (Unicast-Based 
> Rapid Acquisition of Multicast RTP Sessions) to progress as 
> proposed standard.
> 
> Please review and comment on the document by close of 
> business Wednesday, 26th May 2010, i.e. this is a three week 
> WGLC. We have given you an extra week as there is some 
> substance to this document.
> 
> This is intended to be your final chance to review this 
> document before the document is submitted to the IESG for 
> publication, so please take this chance to make all the 
> points you need to make. That includes editorial points as 
> well as technical ones.
> 
> The WG chairs are aware that there are a number of references 
> that are currently progressing behind this document. The WG 
> chairs believe this lag will only become an issue at the 
> final step for publication as an RFC, i.e. the ongoing 
> discussion of those referenced documents should not affect 
> the ability to review and progress this document. If you have 
> another opinion, then please make that opinion known so it 
> can be discussed and appropriately resolved.
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 27 May 2010 15:22:47 +0100

I have read this draft, which is somewhat improved compared to  
previous versions, and have a number of comments.

Technical/editorial suggestions:

- Figure 2 would be clearer if the acronyms "(FT)" and "(BRS)" were  
also included in the boxes labelled "Feedback Target" and "Burst and  
Retrans. Source" respectively.

- Section 6.2 (end of bullet point 2, top of page 19): suggest  
changing "Right before" to "Immediately before" for clarity.

- Section 6.2 (bullet point 3, 2nd paragraph, page 19) states that  
"BRS SHOULD explicitly populate the correct media sender SSRC". Can  
you clarify when it's appropriate not to populate it, and what value  
should be used then?

- Section 6.2 (bullet point 3, 3rd paragraph, page 19): this paragraph  
covers two unrelated topics. Suggest splitting into two before "Note  
that if FT_ap is associated...".

- Section 6.2 (bullet point 3, 4th paragraph, page 19): after "MUST  
explicitly list the media send SSRCs" I suggest adding "denoting the  
stream it wishes to acquire". Also, "MAY accept the request for only  
the media sender SSRC(s) that matched" -> "...only a subset of the...".

- Section 6.2 (bullet point 3, 4th paragraph, page 19): "appropriate  
response code" - be explicit what response code is to be used (also  
occurs in the Reject Responses and Accept Responses bullets following).

- Section 6.2 ("Accept Responses" at the top of page 20): "A  
particularly important field carries" -> "...field in the RAMS-I  
message carries..."

- Section 6.2 (bullet point 4, page 20): "The format of this data  
is..." -> "...of this preamble data is..."

- Page 26: reference I-D.ietf-dccp-rtp is now RFC 5762

- Section 7.2 (end of page 30): it might be useful to briefly explain  
why the media sender SSRC field is set to the SSRC of the packet  
sender (this is presumably because the media sender might not be  
known?).

- Section 7.2, 2nd paragraph: "...are both set to the SSRC of the  
respective primary multicast stream" - since the RAMS-I is sent by the  
BRS, surely they should be set to the SSRC of the BRS? (I realise  
they're the same value, but it's better to be clear on the logical  
distinction).

IPR: as I have mentioned on this list previously, I find some of the  
IPR Licensing Declarations made with respect to this draft unreasonable.

Regards,
Colin

On 20 May 2010, at 13:50, DRAGE, Keith (Keith) wrote:
> (As WG cochair)
>
> A reminder of the WGLC on the above document, which is currently in  
> progress and is programmed to end on 26th May.
>
> Please review this document. There has been so far a disappointing  
> level of indication of people having read this document. Even  
> partial reviews are useful.
>

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 27 May 2010 07:56:59 -0700

Thanks, some comments inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, May 27, 2010 10:23 AM
> To: IETF AVT WG
> Cc: DRAGE, Keith (Keith)
> Subject: Re: [AVT] WGLC for draft-ietf-avt-rapid-acquisition-for-rtp-09
> 

OK.

OK.
 
> you clarify when it's appropriate not to populate it, and what value

There is no good reason not to populate it. If you don't populate it, there is no need to use a value, i.e., the field will not exist anyway.

Magnus asked for this explicit optional TLV in the response message to make it clear to the client that the correct SSRC is different from what it requested for. At that time, we agreed on "SHOULD" but if you prefer, "MUST" also works for me.

OK.

OK.

OK.

> occurs in the Reject Responses and Accept Responses bullets following).

There can be multiple reasons to reject a request. So, there is no one explicit response code. There are several.

OK.

OK.
 
> - Page 26: reference I-D.ietf-dccp-rtp is now RFC 5762

Fixed this along with a few others.
 
> sender (this is presumably because the media sender might not be

Correct and we wanted to unify the client behavior. Will add the reasoning.
 
> they're the same value, but it's better to be clear on the logical

We changed this before from what you said above. So, I suggest we say ... SSRC of the BRS, which has the same SSRC with the primary ....

> IPR Licensing Declarations made with respect to this draft unreasonable.

OK, duly noted.
-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Sun, 30 May 2010 21:35:12 +0100

>> Technical/editorial suggestions:
...
> There is no good reason not to populate it. If you don't populate  
> it, there is no need to use a value, i.e., the field will not exist  
> anyway.
>
> Magnus asked for this explicit optional TLV in the response message  
> to make it clear to the client that the correct SSRC is different  
> from what it requested for. At that time, we agreed on "SHOULD" but  
> if you prefer, "MUST" also works for me.

I'm happy for it to be a SHOULD, but a SHOULD requires an explanation  
of why it's not a MUST (i.e., it should be sent if the correct SSRC  
differs from that requested, but not otherwise).

> There can be multiple reasons to reject a request. So, there is no  
> one explicit response code. There are several.

The current text is ambiguous, and can be read as suggesting that  
there is only one value that's appropriate. If there are several  
possible error codes, it's useful to enumerate the options.

>> respective primary multicast stream" - since the RAMS-I is sent by  
>> the BRS, surely they should be set to the SSRC of the BRS? (I  
>> realise they're the same value, but it's better to be clear on the  
>> logical distinction).
>
> We changed this before from what you said above. So, I suggest we  
> say ... SSRC of the BRS, which has the same SSRC with the primary ....

Yes, since it's clearly confusing :-)

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/