Subject: Re: [AVT] Revised text of the proposal for describing the functionality of Rate Adaptation

From: Zeev Vax <[email-masked]>
Date: Tue, 31 Mar 2009 10:05:42 -0700

Please see inline.

Zeev

-----Original Message-----
From: VAN CAENEGEM Tom [mailto:[email-masked]]
Sent: Monday, March 30, 2009 7:28 AM
To: Peilin YANG; Bill Ver Steeg (versteb); Ali C. Begen (abegen); Zeev Vax
Cc: Roni Even; Tom Taylor; Ye-Kui Wang; [email-masked]
Subject: RE: Revised text of the proposal for describing the functionality of Rate Adaptation

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"

[Zeev Vax] We still need to discuss the exact balance between TLV and fixed fields.

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

[Zeev Vax] I agree with Tom, and his comment is align with what we agreed in the last meeting. Any following RMS-R message might be used by the RS, but it is only recommendation.

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"

[Zeev Vax] Both sound reasonable to me

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

> 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: Peilin YANG <[email-masked]>
Date: Wed, 01 Apr 2009 21:38:40 +0800

Hi Bill, Ali, Tom and Zeev,

Thank you very much for reply and comments, and thank Bill for going through the document with my suggestion.
I also support Ali's advice that we should focus on issue at this time.Once we slove the major issues, we can make quick progress on the converging draft.

The most important issue is the proposal of "fixed vs TLV fields" that Bill suggested to discuss in the mailing list.
Obviously both fixed vs TLV fields have their advantage and disadvantage. For TLV fields, it is easier to allow vendor-specific extensions. But I have no idea if TLV format will influence the maximum number of concurrent of RS. It should be better if there is a small influence.

Another issue is the Sequence Number of RMS-R,as Bill said,it is not good that two message of the 3 have a seqnum type. I also think so. Nevertheless, for RS perhaps it is more clear if there is a seqnum of RMS-R. I have no idea if there is another replaceable way for this.

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]>
日期: 星期三, 四月 1日, 2009 上午1:10
主题: RE: Revised text of the proposal for describing the functionality of Rate Adaptation
收件人: Peilin YANG <[email-masked]>, "Ali C. Begen (abegen)" <[email-masked]>, [email-masked], [email-masked]
抄送: Roni Even <[email-masked]>, Tom Taylor <[email-masked]>, Ye-Kui Wang <[email-masked]>

> Peilin/Zeev
> 
> Thanks for the detailed suggestions.
> 
> I am still considering whether the RMS-I and RMS-T messages need a 
> sequence number. It sounds like we want a sequence number on the 
> RMS-I, but do not want one on the RMS-T. If we have a seqnum on 2 
> of the 3 messages, I am inclined to put one on all of them. Does 
> anybody else have an opinion?
> 
> I should have a straw man proposal for fixed vs TLV fields in the 
> next few hours (worst case tomorrow). We can discuss in detail via 
> email or on a call.
> 
> I am going through the document with Peilin's suggested word-
> smithing changes (as modified by Zeev and Tom). I am incorporating 
> many of the suggested changes, with exceptions noted below-
> 
> 1- Regarding "receiver" and "RTP receiver" - I have changed many 
> instances of "receiver" to "RTP receiver", but left some of the 
> references as "receiver" for readability. I tried to use "RTP 
> receiver" when referencing protocol specific actions, but use 
> "receiver" when discussing a generic device. This is not large 
> point, so some areas could go either way without a loss of clarity.
> 
> 2- Same comments regarding "burst" and "unicast burst". I did 
> eliminate all instances of "RTP burst"
> 
> 
> 
> I should have a document out this evening or tomorrow afternoon 
> (depending on how many interrupts the "real job" gives me today.
> 
> Bvs
> 
> 
> Sent: Monday, March 30, 2009 7:20 AM
> [email-masked]; [email-masked]
> 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 
> 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. 
> 
>     |                       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-
> > 
> **********************************************************************> **
> > ******************
> **********************************************************************> **
> > *****************
> > 
>