Subject: [AVT] Hi Bill and all,

From: Peilin YANG <[email-masked]>
Date: Thu, 26 Mar 2009 11:06:40 +0800

Hi Bill and all,

Thank you very much for concerning Huawei's draft.
I am sorry I haven't participated the SF meeting because I haven't got an American Visa this time.

YK told me an informal result of break session yesterday.
Now I am considering the revised text for describing the functionality of Rate Adaptation for the Burst to the common converging solution and other possible contributing text.

Regards,

Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 26 Mar 2009 15:43:18 -0400

Peilin-

I think we made good progress on the draft. We also have some other
folks looking at how the rate adaptation interacts with the rest of the
signaling. Hopefully we will be able to cleanly incorporate rate
adaptation into the protocol. If you have some suggested text in that
area, that would be great.

Bill VerSteeg 

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: Wednesday, March 25, 2009 8:07 PM
To: Bill Ver Steeg (versteb); Ali C. Begen (abegen);
[email-masked]; [email-masked]; Ye-Kui Wang
Cc: Roni Even; Tom Taylor; Dave Oran (oran); [email-masked]
Subject: Hi Bill and all,

Hi Bill and all,

Thank you very much for concerning Huawei's draft.
I am sorry I haven't participated the SF meeting because I haven't got
an American Visa this time.

YK told me an informal result of break session yesterday.
Now I am considering the revised text for describing the functionality
of Rate Adaptation for the Burst to the common converging solution and
other possible contributing text.

Regards,

Peilin

************************************************************************
******************
 This email and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained here in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this email in error, please
notify the sender by phone or email  immediately and delete it!
 
************************************************************************
*****************

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 30 Mar 2009 16:28:28 +0200

Hi Peilin,

Thanks for your comments. For those that concern editorial stuff, I have no comments back. 
I have comments on three of your suggested modification items, as explained below.
Kind regards
Tom 

Item 1) RMS-I message

You wrote: 
"In the RMS-I message, the present values of Response include 0,1 and 2. The value of 0 indicates that the rapid synchronization request has been rejected. Nevertheless, in the RMS-I message there is not a field to indicate a rejected reason. In my point of view, tt is easier for RR to understand the rejected reason if there is a field of reason. What's more, it is convenient to make statistics report. 

The following Figure is my proposal.  (..) "

TOM : in any case the message formats will be revised to describe parameters as much as possible and/or useful by means of(optional) TLV fields. I believe Bill will make a proposal soon.
I think the "cause of rejection" may be such a TLV field, when the RS indeed rejects the Burst Request. However, I think that may well be a vendor-specific field (for which we need a "type" classifier), as there are many reasons why a request is not honored, but to list them would IMO be out of scope of this draft. So, the question is: do we define a Type for a TLV extension that we call e.g. "reason of rejection" or do we just stick to a Type that only means " vendor specific". I think in both cases, an RR and a RS of a different vendor will not understand each-other, so we may well make it very generic and only define a TLV "type" that means " vendor specific"

Item 2) Section 6.2: Message flows

   3.  Updated Request: The RR MAY send a new RMS-R message with a different
       valule of the field Max Receive Bitrate. The RS MAY use this updated
       bitrate for sending the burst, or refine the value and use the refined 
       value for sending the burst. In any of the cases, the RS MAY send an 
       RMS-I to indicate the bitrate being used. In case the RS receives 
       multiple RMS-R messages at the same time, the latest RMS-R message,
       as indicated by the value of the MSN field in the RMS-R message, MUST 
       be used, and other RMS-R messages SHOULD be discarded.

TOM: I suggest to delete " In case the RS receives 
       multiple RMS-R messages at the same time, the latest RMS-R message,
       as indicated by the value of the MSN field in the RMS-R message, MUST 
       be used, and other RMS-R messages SHOULD be discarded." 

This is because an RS may not support the feature of flexible burst rate adaptation under control of the RR. Hence in that case its implementation may be such that it classifies incoming RMS-R based on version number and internal state. When the RS  has already an active thread for a certain RR and certain SSM (a pending or active burst request) , the RS can simply drop any new RMS-R (with a higher message sequence number) transmitted by that specific RR for that specific ssm.

Item 3) Section on RMS-R message (section 7.1)

      Message Sequence Number (8 bits) :  During rapid synchronization,
      the RMS-R message(s) may be sent more than once.  The first RMS-R
      message SHALL have an MSN value of 0. If a new information is conveyed
      in a new RMS-R message, the MSN value SHALL be incremented by one.

TOM: an RMS-R message may also be sent multiple times with the same information for redundancy purposes. For that reason, I suggest we have instead of " If a new information is conveyed in a new RMS-R message, the MSN value SHALL be incremented by one ", we are more specific and align with the phrasing as used for the RMS-I message:
"This value SHALL NOT be changed if the same RMS-R message is sent to the same RS multiple times for redundancy purposes. If a new information is conveyed in a new RMS-R message, the MSN value SHALL be incremented by one"

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: maandag 30 maart 2009 13:20
To: Bill Ver Steeg (versteb); Ali C. Begen (abegen); VAN CAENEGEM Tom; [email-masked]
Cc: Roni Even; Tom Taylor; Ye-Kui Wang
Subject: Revised text of the proposal for describing the functionality of Rate Adaptation

Dear Bill, Ali, Tom and Zeev,

I added some revised text of the proposal for describing the functionality of Rate Adaptation for the Burst. Please see the attached file. The revised text mainly involves in a new step 3, part of step 1, "7.1. RMS Request" and Figure 3 depicts an example of messaging flow.
I am very glad to disucss it with you. In the attachment file it also includes a little revision. Please see if not suitable for revison.

In addition, I think, the following suggestions also need to be discussed.  

1) IGMP 

In the draft like the following text it only describes the IGMP based on IPv4.

"When a receiver wishes to join the same multicast session, instead of simply issuing   an Internet Group Management Protocol (IGMP) [RFC3376] Join message, it sends a request to the feedback target address for the session asking for the Reference Information. "

Do you think it is necessary to consider MLD protocol based on IPv6 in the document as follows? 

"When a receiver wishes to join the same multicast session, instead of simply issuing   an Internet Group Management Protocol (IGMP) [RFC3376] or Multicast Listener Discovery (MLD) [RFC 3810] Join message, it sends a request to the feedback target address for the session asking for the Reference Information. "

2) RMS-I message

In the RMS-I message, the present values of Response include 0,1 and 2. The value of 0 indicates that the rapid synchronization request has been rejected. Nevertheless, in the RMS-I message there is not a field to indicate a rejected reason. In my point of view, tt is easier for RR to understand the rejected reason if there is a field of reason. What's more, it is convenient to make statistics report. 

The following Figure is my proposal.  

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      MSN      |   Response    |      Reason   |     Rsvd.     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Extended RTP Seqnum of the First Burst Packet          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Earliest IGMP Join Time                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Rapid Synchronization Duration                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Max Burst Bitrate                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 5: FCI field syntax for the RMS Information message

3) "an/the RTP Receiver" and "a/the Receiver"
In the document there are many "an/the RTP Receiver" and "a/the Receiver". Do you think it is necessary to keep these terms to be consistent throughout the document?  I revised them as "an/the RTP Receiver" in the revised proposal text. 

4) "the burst", "a/the unicast burst", "an/the RTP burst" and "the RTP unicast burst"
In the document there are many "the burst", "a/the unicast burst", "an/the RTP burst" and "the RTP unicast burst". Do you think it is necessary to keep these terms to be consistent throughout the document?  I revised them as "a/the unicast burst" in the revised proposal text.

5) "joining the multicast session" and "joining the multicast group"
In the document there is only one "joining the multicast group". I modified "joining the multicast group" to "joining the multicast session"

6) The description of "Updated Responses" of step 3 In the document there is a general description for "Updated Responses" as follows. When I discussed with our development enginerrs, as on-native english speakers they said it is not completely clear to how to implement it.
 
  "3.  Updated Responses:  RS may send more than one RMS-I messages,
       e.g., to update the burst bitrate information when the bitrate is
       adapted and/or to signal RR in real time to join the SSM session."

They said the original text from the draft - draft-levin-avt-rtcp-burst-00 is easier to understand.
So I suggest to add a little description example at the end of the sensence.

The following text is my proposal. The last sensence is largely extracted from the draft - draft-levin-avt-rtcp-burst-00  

  "3.  Updated Responses:  RS may send more than one RMS-I messages,
       e.g., to update the unicast burst bitrate information when the bitrate is
       adapted and/or to signal RR in real time to join the SSM session; to notify 
       RR to join the multicast session when the unicast burst catches up with 
       the original multicast session." 

Regards,
Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email  immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期五, 三月 27日, 2009 上午3:43
主题: RE: Hi Bill and all,
收件人: Peilin YANG <[email-masked]>, "Ali C. Begen (abegen)" <[email-masked]>, [email-masked], [email-masked], Ye-Kui Wang <[email-masked]>
抄送: Roni Even <[email-masked]>, Tom Taylor <[email-masked]>, "Dave Oran (oran)" <[email-masked]>, [email-masked]

> folks looking at how the rate adaptation interacts with the rest of 
> the signaling. Hopefully we will be able to cleanly incorporate rate 
> HUAWEI, which is intended only for the person or entity whose address 
> is listed above. Any use of the information contained here in any way

---

From: David R Oran <[email-masked]>
Date: Mon, 30 Mar 2009 17:02:08 -0400

On Mar 30, 2009, at 10:28 AM, VAN CAENEGEM Tom wrote:

> "In the RMS-I message, the present values of Response include 0,1  
> and 2. The value of 0 indicates that the rapid synchronization  
> request has been rejected. Nevertheless, in the RMS-I message there  
> is not a field to indicate a rejected reason. In my point of view,  
> tt is easier for RR to understand the rejected reason if there is a  
> field of reason. What's more, it is convenient to make statistics  
> report.
>
> TOM : in any case the message formats will be revised to describe  
> parameters as much as possible and/or useful by means of(optional)  
> TLV fields. I believe Bill will make a proposal soon.
> I think the "cause of rejection" may be such a TLV field, when the  
> RS indeed rejects the Burst Request. However, I think that may well  
> be a vendor-specific field (for which we need a "type" classifier),  
> as there are many reasons why a request is not honored, but to list  
> them would IMO be out of scope of this draft. So, the question is:  
> do we define a Type for a TLV extension that we call e.g. "reason of  
> rejection" or do we just stick to a Type that only means " vendor  
> specific". I think in both cases, an RR and a RS of a different  
> vendor will not understand each-other, so we may well make it very  
> generic and only define a TLV "type" that means " vendor specific"
>
>
I think reject reasons are a good idea, with a real IANA error  
registry. Vendor extensibility is fine, but having a comprehensive  
standard error lexicon is just good engineering. I'll note that even  
more important than error codes to the client are the error reporting  
capabilities "northbound" out of the servers. This is because for  
large scale environments lide the ones we see in the sue cases for  
rapid multicast acquisition, we are probably just pushing the problem  
around by sending diagnostic information to the client, who likely  
can't do much of anything with it anyway.

So, I think we should add this for good engineering, but hope people  
realize that in reality it won't help much.

> This is because an RS may not support the feature of flexible burst  
> rate adaptation under control of the RR. Hence in that case its  
> implementation may be such that it classifies incoming RMS-R based  
> on version number and internal state. When the RS  has already an  
> active thread for a certain RR and certain SSM (a pending or active  
> burst request) , the RS can simply drop any new RMS-R (with a higher  
> message sequence number) transmitted by that specific RR for that  
> specific ssm.
>
I agree with Tom. Even an initial RAMS-R the server is free to ignore  
the (optional) bitrate parameter.
> TOM: an RMS-R message may also be sent multiple times with the same  
> information for redundancy purposes. For that reason, I suggest we  
> have instead of " If a new information is conveyed in a new RMS-R  
> message, the MSN value SHALL be incremented by one ", we are more  
> specific and align with the phrasing as used for the RMS-I message:
> "This value SHALL NOT be changed if the same RMS-R message is sent  
> to the same RS multiple times for redundancy purposes. If a new  
> information is conveyed in a new RMS-R message, the MSN value SHALL  
> be incremented by one"
>
I think the problems with mis-ordering of conrol messages spaced at  
greater than an RTT are not so great as to put a lot of effort into  
strict sequence numbering, at least not something beyond what RTCP  
provides itself.

DaveO.

---

From: Peilin YANG <[email-masked]>
Date: Tue, 31 Mar 2009 20:14:49 +0800

Hi Tom,
Thank you very much for your comments. 
Hi Bill, Ali and Zeev, what's your viewpoints?
Kind regards,
Peilin

----- 原邮件 -----
发件人: VAN CAENEGEM Tom <[email-masked]>
日期: 星期一, 三月 30日, 2009 下午10:36
主题: RE: Revised text of the proposal for describing the functionality of Rate Adaptation
收件人: Peilin YANG <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>, "Ali C. Begen (abegen)" <[email-masked]>, [email-masked]
抄送: Roni Even <[email-masked]>, Tom Taylor <[email-masked]>, Ye-Kui Wang <[email-masked]>, [email-masked]

> request has been rejected. Nevertheless, in the RMS-I message 
> there is not a field to indicate a rejected reason. In my point of 
> view, tt is easier for RR to understand the rejected reason if 
> there is a field of reason. What's more, it is convenient to make 
> statistics report. 
> 
> RS indeed rejects the Burst Request. However, I think that may 
> well be a vendor-specific field (for which we need a "type" 
> classifier), as there are many reasons why a request is not 
> honored, but to list them would IMO be out of scope of this draft. 
> So, the question is: do we define a Type for a TLV extension that 
> we call e.g. "reason of rejection" or do we just stick to a Type 
> that only means " vendor specific". I think in both cases, an RR 
> and a RS of a different vendor will not understand each-other, so 
> we may well make it very generic and only define a TLV "type" that 
> means " vendor specific"
> 
> 
> 
> 
> 
>   3.  Updated Request: The RR MAY send a new RMS-R message with a 
> different       valule of the field Max Receive Bitrate. The RS 
> MAY use this updated
>       multiple RMS-R messages at the same time, the latest RMS-R 
> message,       as indicated by the value of the MSN field in the 
> RMS-R message, MUST 
>       multiple RMS-R messages at the same time, the latest RMS-R 
> message,       as indicated by the value of the MSN field in the 
> RMS-R message, MUST 
> This is because an RS may not support the feature of flexible 
> burst rate adaptation under control of the RR. Hence in that case 
> its implementation may be such that it classifies incoming RMS-R 
> based on version number and internal state. When the RS  has 
> already an active thread for a certain RR and certain SSM (a 
> pending or active burst request) , the RS can simply drop any new 
> RMS-R (with a higher message sequence number) transmitted by that 
> specific RR for that specific ssm.
> 
> 
> 
> 
>      Message Sequence Number (8 bits) :  During rapid 
> synchronization,      the RMS-R message(s) may be sent more than 
> once.  The first RMS-R
> TOM: an RMS-R message may also be sent multiple times with the 
> same information for redundancy purposes. For that reason, I 
> suggest we have instead of " If a new information is conveyed in a 
> new RMS-R message, the MSN value SHALL be incremented by one ", we 
> are more specific and align with the phrasing as used for the RMS-
> I message:
> information is conveyed in a new RMS-R message, the MSN value 
> SHALL be incremented by one"
> 
> 
> 
> 
> I added some revised text of the proposal for describing the 
> functionality of Rate Adaptation for the Burst. Please see the 
> attached file. The revised text mainly involves in a new step 3, 
> part of step 1, "7.1. RMS Request" and Figure 3 depicts an example 
> of messaging flow.
> I am very glad to disucss it with you. In the attachment file it 
> also includes a little revision. Please see if not suitable for 
> revison.
> "When a receiver wishes to join the same multicast session, 
> instead of simply issuing   an Internet Group Management Protocol 
> (IGMP) [RFC3376] Join message, it sends a request to the feedback 
> target address for the session asking for the Reference 
> Information. "
> 
> "When a receiver wishes to join the same multicast session, 
> instead of simply issuing   an Internet Group Management Protocol 
> (IGMP) [RFC3376] or Multicast Listener Discovery (MLD) [RFC 3810] 
> Join message, it sends a request to the feedback target address 
> for the session asking for the Reference Information. "
> 
> 2) RMS-I message
> 
> In the RMS-I message, the present values of Response include 0,1 
> request has been rejected. Nevertheless, in the RMS-I message 
> there is not a field to indicate a rejected reason. In my point of 
> view, tt is easier for RR to understand the rejected reason if 
> there is a field of reason. What's more, it is convenient to make 
> statistics report. 
> 
>     |                       Max Burst Bitrate                     
>  |
> In the document there are many "an/the RTP Receiver" and "a/the 
> Receiver". Do you think it is necessary to keep these terms to be 
> consistent throughout the document?  I revised them as "an/the RTP 
> Receiver" in the revised proposal text. 
> 
> In the document there are many "the burst", "a/the unicast burst", 
> "an/the RTP burst" and "the RTP unicast burst". Do you think it is 
> necessary to keep these terms to be consistent throughout the 
> document?  I revised them as "a/the unicast burst" in the revised 
> proposal text.
> 
> In the document there is only one "joining the multicast group". I 
> modified "joining the multicast group" to "joining the multicast 
> session"
> 6) The description of "Updated Responses" of step 3 In the 
> document there is a general description for "Updated Responses" as 
> follows. When I discussed with our development enginerrs, as on-
> native english speakers they said it is not completely clear to 
> how to implement it.
> 
> The following text is my proposal. The last sensence is largely 
> extracted from the draft - draft-levin-avt-rtcp-burst-00  
> 
> This email and its attachments contain confidential information 
> from HUAWEI, which is intended only for the person or entity whose 
> address is listed above. Any use of the information contained here 
> in any way (including, but not limited to, total or partial 
> disclosure, reproduction, or dissemination) by persons other than 
> the intended recipient(s) is prohibited. If you receive this email 
> in error, please notify the sender by phone or email  immediately 
> and delete it!
> 
> 收件人: Peilin YANG <[email-masked]>, "Ali C. Begen (abegen)" 
> <[email-masked]>, [email-masked], 
> [email-masked], Ye-Kui Wang <[email-masked]>
> 抄送: Roni Even <[email-masked]>, Tom Taylor 
> <[email-masked]>, "Dave Oran (oran)" <[email-masked]>, 
> [email-masked]
> > Peilin-
> > 
> **********************************************************************> **
> > ******************
> **********************************************************************> **
> > *****************
> > 
>