Subject: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-01.txt

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 13 Jul 2009 12:30:35 +0300

Hi Bill, Ali, All,

It has been discussed earlier that the purpose of each field provided in
each message should at least be briefly mentioned, if the exact usage needs
not to be provided. From the semantics of the field Min RAMS Buffer Fill
Requirement (32 bits) in the RAMS-R message, copied below for convenience, I
still don't know why the RS would need this piece of information. Could you
please clarify? I also have some clarification questions interleaved in the
copied text regarding the semanticfs itself. 

-----start of text-----
   o  Min RAMS Buffer Fill Requirement (32 bits):  Optional TLV element
      that denotes the minimum number of octets of content the RTP
      receiver desires to have in its buffer as a result of the unicast
      burst.

[YK]: What exactly does "as a result of the unicast burst" mean? At which
moment during the RAMS process is the amount of data in the receiver buffer
from the unicast burst measured (and counted as the result)?

      The RTP receiver may have knowledge of its buffering requirements.
      These requirements may be application or device specific.  For
      instance, the receiver may need to have a certain amount of data
      in its application buffer to handle interdependency within the
      data.  If RS is told the buffering ability of the receiver, it may
      tailor the burst more precisely.  The methods used by the receiver
      to determine this value are application specific, and thus, out of
      scope.

      If specified, the amount of backfill that will be provided by the
      unicast burst SHOULD NOT be smaller than this value since it will
      not be able to build up the desired level of buffer at RR and may
      cause buffer underruns.

[YK]: What exactly does "backfill" mean? At which moment during the RAMS
process is "backfill" measured? I guess this is similar as above for "as a
result of the unicast burst", but I am not sure from the text. 

      Type:  TBD

      Length:  TBD
-----end of text-----

It would very helpful for readers to understand the protocol if the reason
of having each field is briefly described, e.g. by just mentioning what the
receiver of the field can do based on the information. Is it possible to add
this for each field when the purpose is not obvious?

Thanks!

BR, YK

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 14 Jul 2009 07:00:53 -0700

Hi YK,

> -----Original Message-----
> From: Ye-Kui Wang [mailto:[email-masked]]
> Sent: Monday, July 13, 2009 5:31 AM
> To: [email-masked]
> Cc: [email-masked]; Ali C. Begen (abegen)
> Subject: Comments on draft-ietf-avt-rapid-acquisition-for-rtp-01.txt
> 
> 
> 
> Hi Bill, Ali, All,
> 

Each end-receiver (RR) may have a different min buffer size requirement before it actually starts doing something with the data. For example, RR_1 may be using a large de-jittering buffer and it may need to signal this req to RS so that the burst that will be provided will be sufficient to backfill this min buffer. Note that in a video application, the mpeg decoding buffering is separate than this buffer. We could say that this field denotes the amount of min buffering before the mpeg decoding buffer starts filling.

Remember that this is optional.

> result of the unicast burst", but I am not sure from the text.

You can think of it as "fill" but I guess "backfill" sounds more appropriate as we are filling the buffer with "older" data.

> this for each field when the purpose is not obvious?

What other fields are not clear? We are trying to improve the explanations but we need to know which part is unclear.

-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 14 Jul 2009 17:36:25 +0300

Hi Ali, 

Thanks for your reply. 

OK, so this (Min RAMS Buffer Fill Requirement (32 bits)) is basically the
min size of the RTP reception buffer, which is separate from the decoder
buffer. 

The text in the draft says that this is the "the minimum number of octets of
content the RTP receiver desires to have in its buffer as a result of the
unicast burst". How do I connect this two different phrases? What I don't
understand includes two connected aspects: 1) Why to use the words "as a
result of the unicast burst" in describing the semantics, as the RTP
reception buffering is not specific to the case using the unicast burst? 2)
Does this information (signalled from RR to RS) help RS on anything that
would affect the RAMS process? This second part trigged my original question
and I think should be clarified in the text. For example, the semantics for
"Max RAMS Buffer Fill Requirement (32 bits)" include "If RS knows the
buffering ability of the receiver, it may tailor the burst more precisely",
which at least provides some clue what RS can do by using the information,
though it would be nicer if it can be explained in a bit more detail on how
to utilize the information to tailor the burst more precisely.

Regarding your last question below, I just briefly checked all message
fields of all the messages, and found that the purposes of others fields
(other than "Min RAMS Buffer Fill Requirement (32 bits)" and "Max RAMS
Buffer Fill Requirement (32 bits)") are either obvious or specified.
Therefore, it would sufficient if you could address my above questions and
comments on these two fields.

BR, YK

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Tuesday, July 14, 2009 5:01 PM
> To: Ye-Kui Wang; [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on 
> draft-ietf-avt-rapid-acquisition-for-rtp-01.txt
> 
> Hi YK,
> 
> > It has been discussed earlier that the purpose of each 
> field provided 
> > in each message should at least be briefly mentioned, if the exact 
> > usage needs not to be provided. From the semantics of the field Min 
> > RAMS Buffer Fill Requirement (32 bits) in the RAMS-R 
> message, copied 
> > below for convenience, I still don't know why the RS would 
> need this 
> > piece of information. Could you please clarify? I also have some 
> > clarification questions interleaved in the copied text 
> regarding the semanticfs itself.
> > 
> > -----start of text-----
> > [YK]: What exactly does "as a result of the unicast burst" mean? At 
> > which moment during the RAMS process is the amount of data in the 
> > receiver buffer from the unicast burst measured (and 
> counted as the result)?
> 
> Each end-receiver (RR) may have a different min buffer size 
> requirement before it actually starts doing something with 
> the data. For example, RR_1 may be using a large de-jittering 
> buffer and it may need to signal this req to RS so that the 
> burst that will be provided will be sufficient to backfill 
> this min buffer. Note that in a video application, the mpeg 
> decoding buffering is separate than this buffer. We could say 
> that this field denotes the amount of min buffering before 
> the mpeg decoding buffer starts filling.
> 
> > [YK]: What exactly does "backfill" mean? At which moment during the 
> > RAMS process is "backfill" measured? I guess this is 
> similar as above 
> > for "as a result of the unicast burst", but I am not sure 
> from the text.
> 
> You can think of it as "fill" but I guess "backfill" sounds 
> more appropriate as we are filling the buffer with "older" data.
> 
>  
> >       Type:  TBD
> > 
> >       Length:  TBD
> > -----end of text-----
> > 
> > It would very helpful for readers to understand the protocol if the 
> > reason of having each field is briefly described, e.g. by just 
> > mentioning what the receiver of the field can do based on the 
> > information. Is it possible to add this for each field when 
> the purpose is not obvious?
> 
> What other fields are not clear? We are trying to improve the 
> explanations but we need to know which part is unclear.
> 
> -acbegen
> 
> > Thanks!
> > 
> > BR, YK
> > 
> > 
> 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 14 Jul 2009 09:26:03 -0700

Hi YK,

> Sent: Tuesday, July 14, 2009 10:36 AM
> To: Ali C. Begen (abegen); [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-avt-rapid-acquisition-for-rtp-01.txt
> 
> 
> Hi Ali,
> 
> Thanks for your reply.
> 

We would welcome your suggested wording.

> would affect the RAMS process? This second part trigged my original question

It sure does. If RS has multiple options for the burst starting point, it will choose accordingly. If any of them satisfies what RR wants, it may deny the RAMS request. Same thing for the max buffer req.

> to utilize the information to tailor the burst more precisely.

There is a fine line here between giving out the simple definition and getting into the implementation details. It was previously agreed that we refrained from doing the latter. I believe this is an implementation issue and does not need to be detailed in here.

> comments on these two fields.

Sounds good. As I mentioned above, if you have suggested wording that will not go into the implementation issues, please let us know.

-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 15 Jul 2009 11:07:48 +0300

Hi Ali,

> > OK, so this (Min RAMS Buffer Fill Requirement (32 bits)) is 
> basically 
> > the min size of the RTP reception buffer, which is separate 
> from the 
> > decoder buffer.
> > 
> > The text in the draft says that this is the "the minimum number of 
> > octets of content the RTP receiver desires to have in its 
> buffer as a 
> > result of the unicast burst". How do I connect this two different 
> > phrases? What I don't understand includes two connected aspects: 1) 
> > Why to use the words "as a result of the unicast burst" in 
> describing 
> > the semantics, as the RTP reception buffering is not 
> specific to the 
> > case using the unicast burst? 2)
> 

I will try after I feel I really understand. See below. 

> 
> > Does this information (signalled from RR to RS) help RS on anything 
> > that would affect the RAMS process? This second part trigged my 
> > original question
> 
> It sure does. If RS has multiple options for the burst 
> starting point, it will choose accordingly. 

So you mean that the RS may choose a burst starting point that is not the
latest one. What benefit can this bring? I mean, given the min RTP reception
buffer requirement for the RR, the RR can just wait for the RTP reception
buffer to reach that level before feeding data to the decoder, regardless of
whether all the data in the RTP reception buffer is from the unicast burst,
or multicast, or partly from the unicast and partly from the multicast.
Furthermore, regardless of which burst starting point being chosen, at some
moment, the RTP reception buffer will contain data from both the unicast
burst and the multicast burst. Therefore, to me, choosing a burst starting
piont other than the latest one does not bring any benefit compared to
choosing the latest one, while it does increase the playback delay (which is
not a good thing). Am I missing anything here?

> If any of them 
> satisfies what RR wants, it may deny the RAMS request. 

Here, I guess you mean "If none of them satisfies what RR wants, RS may deny
the RAMS request"?

> Same thing for the max buffer req.
> 

OK. 

> > and I think should be clarified in the text. For example, the 
> > semantics for "Max RAMS Buffer Fill Requirement (32 bits)" 
> include "If 
> > RS knows the buffering ability of the receiver, it may tailor the 
> > burst more precisely", which at least provides some clue 
> what RS can 
> > do by using the information, though it would be nicer if it can be 
> > explained in a bit more detail on how to utilize the 
> information to tailor the burst more precisely.
> 
> There is a fine line here between giving out the simple 
> definition and getting into the implementation details. It 
> was previously agreed that we refrained from doing the 
> latter. I believe this is an implementation issue and does 
> not need to be detailed in here.
> 

I understand. In this case, it would be good to give some details in an
informative note, to the extent that readers can understand the specific use
and probably imaging other uses. This way, the purpose is clarified well to
readers, and implementation details, which should not be binding, are not in
binding spec text. From the current text, I am not sure that future
implementers of the potential RFC can figure out an appropriate
implementation of RR to take the advantage of the information when
available.

Again, if I feel myself really understand here for the two fields (with your
help), I would be very willing to make some suggested wordings. To be deadly
clear, for Min RAMS Buffer Fill Requirement, see my comments and questions
above. For Max RAMS Buffer Fill Requirement, still I don't know by reading
the text how to use the information to tailor the burst more precisely.

BR, YK

> > fields of all the messages, and found that the purposes of others 
> > fields (other than "Min RAMS Buffer Fill Requirement (32 bits)" and 
> > "Max RAMS Buffer Fill Requirement (32 bits)") are either 
> obvious or specified.
> > Therefore, it would sufficient if you could address my 
> above questions 
> > and comments on these two fields.
> 
> Sounds good. As I mentioned above, if you have suggested 
> wording that will not go into the implementation issues, 
> please let us know.
> 
> -acbegen
>  
> > BR, YK
> > 
> > > > Subject: Comments on 
> > > > usage needs not to be provided. From the semantics of the field 
> > > > Min RAMS Buffer Fill Requirement (32 bits) in the RAMS-R
> > > message, copied
> > > > [YK]: What exactly does "as a result of the unicast 
> burst" mean? 
> > > > At which moment during the RAMS process is the amount 
> of data in 
> > > > the receiver buffer from the unicast burst measured (and
> > > counted as the result)?
> > >
> > > requirement before it actually starts doing something 
> with the data. 
> > > For example, RR_1 may be using a large de-jittering buffer and it 
> > > may need to signal this req to RS so that the burst that will be 
> > > provided will be sufficient to backfill this min buffer. 
> Note that 
> > > in a video application, the mpeg decoding buffering is 
> separate than 
> > > this buffer. We could say that this field denotes the 
> amount of min 
> > > buffering before the mpeg decoding buffer starts filling.
> > >
> > > > [YK]: What exactly does "backfill" mean? At which moment during 
> > > > the RAMS process is "backfill" measured? I guess this is
> > > similar as above
> > > You can think of it as "fill" but I guess "backfill" sounds more 
> > > appropriate as we are filling the buffer with "older" data.
> > >
> > >
> > > >       Type:  TBD
> > > >
> > > >       Length:  TBD
> > > > -----end of text-----
> > > >
> > > > It would very helpful for readers to understand the protocol if 
> > > > the reason of having each field is briefly described, 
> e.g. by just

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 15 Jul 2009 08:17:30 -0700

Hi YK,

> not a good thing). Am I missing anything here?

This min/max buffer req is an additional level of information with which we try to choose the most appropriate burst starting point. Another option as you indicated is to always choose the latest one. We need to build up a buffer that will at least allow for one retransmission (if ret is desired).

> > I any of them

Right.
 
> binding spec text. From the current text, I am not sure that future

Remember that these fields are all optional. So, there is not much binding info. We will try to word it better in the next version based on the suggestions.

> the text how to use the information to tailor the burst more precisely.

Depending on the bitrate and the max buffer available at the receiver, the burst may overflow the receiver's buffer. If this has a potential to become a problem, server should know about this. RR will start draining from the buffer as soon as it starts decoding, but an overflow may still occur.

Keep in mind that it is not the purpose of our draft to specify how the burst starting point should be chosen. But, of course, we should avoid any text that sounds "binding."

-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 15 Jul 2009 20:34:04 +0300

Hi Ali,

> > So you mean that the RS may choose a burst starting point 
> that is not 
> > the latest one. What benefit can this bring? I mean, given 
> the min RTP 
> > reception buffer requirement for the RR, the RR can just 
> wait for the 
> > RTP reception buffer to reach that level before feeding data to the 
> > decoder, regardless of whether all the data in the RTP reception 
> > buffer is from the unicast burst, or multicast, or partly 
> from the unicast and partly from the multicast.
> > Furthermore, regardless of which burst starting point being 
> chosen, at 
> > some moment, the RTP reception buffer will contain data 
> from both the 
> > unicast burst and the multicast burst. Therefore, to me, choosing a 
> > burst starting piont other than the latest one does not bring any 
> > benefit compared to choosing the latest one, while it does increase 
> > the playback delay (which is not a good thing). Am I 
> missing anything here?
> 
> This min/max buffer req is an additional level of information 
> with which we try to choose the most appropriate burst 
> starting point. Another option as you indicated is to always 
> choose the latest one. We need to build up a buffer that will 
> at least allow for one retransmission (if ret is desired).
> 

Why buffering for retransmission needs choosing an earlier burst starting
point than the latest one? Even retransmission results in a relatively long
delay and hence a relatively large reception buffer is needed, as I
commented above, the RR can just wait for reception buffer to reach the
desired level before feeding data to the decoder, regardless of whether the
packets in the buffer are from the unicast burst or the multicast. So again,
why choosing an earlier burst starting point may help? Sorry for keep
asking. But if there is no clear benefit of using the information of RR's
min buffer requirement by RS, it then does not make sense for the
draft/standard to support signaling of the information at all, even
optionally. 

> > Again, if I feel myself really understand here for the two fields 
> > (with your help), I would be very willing to make some suggested 
> > wordings. To be deadly clear, for Min RAMS Buffer Fill Requirement, 
> > see my comments and questions above. For Max RAMS Buffer Fill 
> > Requirement, still I don't know by reading the text how to 
> use the information to tailor the burst more precisely.
> 
> Depending on the bitrate and the max buffer available at the 
> receiver, the burst may overflow the receiver's buffer. If 
> this has a potential to become a problem, server should know 
> about this. RR will start draining from the buffer as soon as 
> it starts decoding, but an overflow may still occur.
> 

This implies that RS may choose the max unicast burst sending rate that fits
the available bandwidth and that overflow will not happen. This is now
understood. Thanks! I have no more doubt for the existence of the max
buffer. If a couple of sentences summarizing our discussions on this, that's
to me already a good text. 

> Keep in mind that it is not the purpose of our draft to 
> specify how the burst starting point should be chosen. 

Sure. I was not commenting that this should be. The comments were (finally)
about whether and why the field (the min buffer req) is useful at all. 

BR, YK

---

From: Zeev Vax <[email-masked]>
Date: Wed, 15 Jul 2009 20:55:26 +0000

You are right that for the burst it make most sense to select the latest, but  the start point of the burst have implication on the total buffered packets the client would have. This is important for the steady state, it define the max packet lost that can be supported.

Zeev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui Wang
Sent: Wednesday, July 15, 2009 10:34 AM
To: 'Ali C. Begen (abegen)'; [email-masked]
Subject: Re: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-01.txt

Hi Ali,

BR, YK

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 16 Jul 2009 10:15:42 +0300

> You are right that for the burst it make most sense to select 
> the latest, but  the start point of the burst have 
> implication on the total buffered packets the client would 
> have. 

If you say "... the start point of the burst has implication on the total
buffered packets the client would have AT CERTAIN TIME INSTANCES", I would
agree. However, this does not tell that choosing an earlier start point may
give better performance. If yes, what is the benefit? And how is the benefit
achived?

>This is important for the steady state, it define the 

What state?

> max packet lost that can be supported.

I guess you meant "the max number of lost packets"? Or do you mean "the max
size of a lost packet"? 

BR, YK 

> From: Zeev Vax [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 11:55 PM
> To: Ye-Kui Wang; 'Ali C. Begen (abegen)'; [email-masked]
> Subject: RE: [AVT] Comments on 
> You are right that for the burst it make most sense to select 
> the latest, but  the start point of the burst have 
> implication on the total buffered packets the client would 
> have. This is important for the steady state, it define the 
> max packet lost that can be supported.
> 
> Zeev
> 
> Subject: Re: [AVT] Comments on 
> > This min/max buffer req is an additional level of information with 
> > which we try to choose the most appropriate burst starting point. 
> > Another option as you indicated is to always choose the 
> latest one. We 
> > need to build up a buffer that will at least allow for one 
> > retransmission (if ret is desired).
> >
> 
> Why buffering for retransmission needs choosing an earlier 
> burst starting point than the latest one? Even retransmission 
> results in a relatively long delay and hence a relatively 
> large reception buffer is needed, as I commented above, the 
> RR can just wait for reception buffer to reach the desired 
> level before feeding data to the decoder, regardless of 
> whether the packets in the buffer are from the unicast burst 
> or the multicast. So again, why choosing an earlier burst 
> starting point may help? Sorry for keep asking. But if there 
> is no clear benefit of using the information of RR's min 
> buffer requirement by RS, it then does not make sense for the 
> draft/standard to support signaling of the information at 
> all, even optionally.
> 
> > Depending on the bitrate and the max buffer available at 
> the receiver, 
> > the burst may overflow the receiver's buffer. If this has a 
> potential 
> > to become a problem, server should know about this. RR will start 
> > draining from the buffer as soon as it starts decoding, but an 
> > overflow may still occur.
> >
> 
> This implies that RS may choose the max unicast burst sending 
> rate that fits the available bandwidth and that overflow will 
> not happen. This is now understood. Thanks! I have no more 
> doubt for the existence of the max buffer. If a couple of 
> sentences summarizing our discussions on this, that's to me 
> already a good text.
> 
> > Keep in mind that it is not the purpose of our draft to specify how 
> > the burst starting point should be chosen.
> 
> Sure. I was not commenting that this should be. The comments 
> were (finally) about whether and why the field (the min 
> buffer req) is useful at all.
> 
> BR, YK
> 
>

---

From: Zeev Vax <[email-masked]>
Date: Thu, 16 Jul 2009 16:22:16 +0000

Choosing an earlier start point would mean more packet in the buffer at the end of the burst. When the RR is tune to the multicast stream (steady state), it has in its buffer the same amount of data in milliseconds as the distance between  the start point and the multicast at the beginning of the burst.

I meant the max number of lost packets.

Zeev

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]]
Sent: Thursday, July 16, 2009 12:16 AM
To: Zeev Vax; 'Ali C. Begen (abegen)'; [email-masked]
Subject: RE: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-01.txt

What state?

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 17 Jul 2009 10:46:07 +0300

> Choosing an earlier start point would mean more packet in the 
> buffer at the end of the burst. When the RR is tune to the 
> multicast stream (steady state), it has in its buffer the 
> same amount of data in milliseconds as the distance between  
> the start point and the multicast at the beginning of the burst.

Right, and this was understood. But again this does not tell why choosing an
earlier starting point can be better, in terms of any concrete performance
improvement, like reduced delay, smoother playback, improved video quality,
.... 

Why can't you guys just give a simple concrete example? I am just trying to
find out a real benefit of signaling the min buffer req, for which so far
the only identified possible usefulness is to help RS decide choosing the
burst starting point. However, if choosing an earlier starting point than
the latest one can never bring any concrete benefit, then the signaling is
useless and should not be there. So, just a single example of concrete
benefit of choosing an earlier starting point would be enough.

BR, YK 

> Sent: Thursday, July 16, 2009 7:22 PM
> Choosing an earlier start point would mean more packet in the 
> buffer at the end of the burst. When the RR is tune to the 
> multicast stream (steady state), it has in its buffer the 
> same amount of data in milliseconds as the distance between  
> the start point and the multicast at the beginning of the burst.
> 
> > You are right that for the burst it make most sense to select the 
> > latest, but  the start point of the burst have implication on the 
> > total buffered packets the client would have.
> 
> If you say "... the start point of the burst has implication 
> on the total buffered packets the client would have AT 
> CERTAIN TIME INSTANCES", I would agree. However, this does 
> not tell that choosing an earlier start point may give better 
> performance. If yes, what is the benefit? And how is the 
> benefit achived?
> 
> I guess you meant "the max number of lost packets"? Or do you 
> mean "the max size of a lost packet"?
> 
> BR, YK
> 
> > You are right that for the burst it make most sense to select the 
> > latest, but  the start point of the burst have implication on the 
> > total buffered packets the client would have. This is important for 
> > the steady state, it define the max packet lost that can be 
> supported.
> >
> > Zeev
> >
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > Ye-Kui Wang
> > Why buffering for retransmission needs choosing an earlier burst 
> > starting point than the latest one? Even retransmission 
> results in a 
> > relatively long delay and hence a relatively large 
> reception buffer is 
> > needed, as I commented above, the RR can just wait for reception 
> > buffer to reach the desired level before feeding data to 
> the decoder, 
> > regardless of whether the packets in the buffer are from 
> the unicast 
> > burst or the multicast. So again, why choosing an earlier burst 
> > starting point may help? Sorry for keep asking. But if there is no 
> > clear benefit of using the information of RR's min buffer 
> requirement 
> > by RS, it then does not make sense for the draft/standard 
> to support 
> > signaling of the information at all, even optionally.
> >
> > This implies that RS may choose the max unicast burst sending rate 
> > that fits the available bandwidth and that overflow will 
> not happen. 
> > This is now understood. Thanks! I have no more doubt for 
> the existence 
> > of the max buffer. If a couple of sentences summarizing our 
> > discussions on this, that's to me already a good text.
> >
> specify how 
> > Sure. I was not commenting that this should be. The comments were 
> > (finally) about whether and why the field (the min buffer req) is 
> > useful at all.
> >
> > BR, YK
> >
> >

---

From: Zeev Vax <[email-masked]>
Date: Fri, 17 Jul 2009 16:18:03 +0000

As I said the justification is not about the FCC, it is about packet lost post the burst (build a buffer so the client can handle packets lost).
So in a sense you can say it is for smother playback post the FCC of the multicast stream.

Zeev

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]]
Sent: Friday, July 17, 2009 12:46 AM
To: Zeev Vax; 'Ali C. Begen (abegen)'; [email-masked]
Subject: RE: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-01.txt

BR, YK