[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Revised text of the proposal for describing the functionality of Rate Adaptation
Hi Tom,
Thank you very much for your comments.
Hi Bill, Ali and Zeev, what's your viewpoints?
Kind 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!
*****************************************************************************************
----- 原邮件 -----
发件人: VAN CAENEGEM Tom <Tom.Van_Caenegem at alcatel-lucent.be>
日期: 星期一, 三月 30日, 2009 下午10:36
主题: RE: Revised text of the proposal for describing the functionality of Rate Adaptation
收件人: Peilin YANG <yangpeilin at huawei.com>, "Bill Ver Steeg (versteb)" <versteb at cisco.com>, "Ali C. Begen (abegen)" <abegen at cisco.com>, zeevvax at microsoft.com
抄送: Roni Even <ron.even.tlv at gmail.com>, Tom Taylor <tom.taylor at rogers.com>, Ye-Kui Wang <yekuiwang at huawei.com>, avt at ietf.org
> 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:yangpeilin at huawei.com]
> Sent: maandag 30 maart 2009 13:20
> To: Bill Ver Steeg (versteb); Ali C. Begen (abegen); VAN CAENEGEM
> Tom; zeevvax at microsoft.com
> 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)" <versteb at cisco.com>
> 日期: 星期五, 三月 27日, 2009 上午3:43
> 主题: RE: Hi Bill and all,
> 收件人: Peilin YANG <yangpeilin at huawei.com>, "Ali C. Begen (abegen)"
> <abegen at cisco.com>, Tom.Van_Caenegem at alcatel-lucent.be,
> zeevvax at microsoft.com, Ye-Kui Wang <yekuiwang at huawei.com>
> 抄送: Roni Even <ron.even.tlv at gmail.com>, Tom Taylor
> <tom.taylor at rogers.com>, "Dave Oran (oran)" <oran at cisco.com>,
> avt at ietf.org
> > 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:yangpeilin at huawei.com]
> > Sent: Wednesday, March 25, 2009 8:07 PM
> > To: Bill Ver Steeg (versteb); Ali C. Begen (abegen);
> > Tom.Van_Caenegem at alcatel-lucent.be; zeevvax at microsoft.com; Ye-
> Kui Wang
> > Cc: Roni Even; Tom Taylor; Dave Oran (oran); avt at ietf.org
> > 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!
> >
> >
> **********************************************************************> **
> > *****************
> >
>