|
Please see inline. Zeev -----Original Message----- 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: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! > >
********************************************************************** > ** > ***************** > |