[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 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)" <versteb at cisco.com>
日期: 星期三, 四月 1日, 2009 上午1:10
主题: RE: Revised text of the proposal for describing the functionality of Rate Adaptation
收件人: 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
抄送: Roni Even <ron.even.tlv at gmail.com>, Tom Taylor <tom.taylor at rogers.com>, Ye-Kui Wang <yekuiwang at huawei.com>
> 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
>
>
> -----Original Message-----
> From: Peilin YANG [mailto:yangpeilin at huawei.com]
> Sent: Monday, March 30, 2009 7:20 AM
> To: Bill Ver Steeg (versteb); Ali C. Begen (abegen);
> Tom.Van_Caenegem at alcatel-lucent.be; 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!
> >
> >
> **********************************************************************> **
> > *****************
> >
>