[Tmrg-interest] Re: Tmrg-interest digest, Vol 1 #47 - 4 msgs

[[e-mail] ([e-mail])]

Dear All,

Packet drop rate should be included as a mean value

metrics to describe loss bursts can also be included.
Mean and variance of the size of the loss burst can be useful
to better characterize the loss pattern

In ATM specification, there was a metric called rate of block of
cells severely damaged which gives the mean rate of loss bursts

nelson fonseca

> Send Tmrg-interest mailing list submissions to
> 	[e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
>
> You can reach the person managing the list at
> 	[e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tmrg-interest digest..."
>
>
> Today's Topics:
>
>    1. Re: the most recent version of draft-irtf-tmrg-metrics (Janardhan
> Iyengar)
>    2. RE: the most recent version of draft-irtf-tmrg-metrics (Moore, Sean
> (Sean))
>    3. Re: the most recent version of draft-irtf-tmrg-metrics (Armando L.
> Caro, Jr.)
>    4. RE: the most recent version of draft-irtf-tmrg-metrics (Moore, Sean
> (Sean))
>
> --__--__--
>
> Message: 1
> Date: Mon, 19 Sep 2005 18:02:45 -0400 (EDT)
> From: Janardhan Iyengar <[e-mail]>
> To: Sally Floyd <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Tmrg-interest] the most recent version of
> draft-irtf-tmrg-metrics
>
> Sally,
>
> This is a very meaningful task, and long in waiting.
>
> I have a suggestion regarding the metric "packet drop rates". IMHO, it is
> more meaningful to have a metric, if possible, a probability distribution,
> that is rich enough to capture more than just a "rate of packet drops".
> I'm open to what this metric should be, but I do feel that this definition
> should be richer.
>
> At the least, a metric such as a "packet drop event rate" which captures
> the burstiness of drops could be included, in addition to "packet drop
> rate".
>
> I'm interested in hearing what others have to say.
>
> regards,
> jana
>
>
> On Mon, 29 Aug 2005, Sally Floyd wrote:
>
>> I have put a copy of draft-irtf-tmrg-metrics-01a.txt,
>> under construction for draft-irtf-tmrg-metrics-01, on the tmrg
>> web site.  It contains the modifications that I made today.
>> People giving feedback, or suggesting references to add,
>> might want to refer to this as the most version (even
>> though it won't be submitted to the internet-drafts editor
>> until it has stabilized a bit).
>>
>> http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-01a.txt
>>
>> - Sally
>> http://www.icir.org/tmrg/
>>
>> _______________________________________________
>> Tmrg-interest mailing list
>> [e-mail]
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>>
>
> ---------------------------------------------------------------
> Janardhan R. Iyengar           http://www.cis.udel.edu/~iyengar
> Protocol Engineering Lab  --   CIS   --  University Of Delaware
> ---------------------------------------------------------------
>
>
> --__--__--
>
> Message: 2
> Subject: RE: [Tmrg-interest] the most recent version of
> draft-irtf-tmrg-metrics
> Date: Mon, 19 Sep 2005 19:59:15 -0400
> From: "Moore, Sean \(Sean\)" <[e-mail]>
> To: "Janardhan Iyengar" <[e-mail]>,
>         "Sally Floyd" <[e-mail]>
> Cc: <[e-mail]>
>
> I have a suggestion.
>
> When computing quality measures for VoIP flows, a similar issue arises
> in which the average packet loss rate doesn't capture the quality
> problems that arise from bursty packet loss.  RFC 3611 describes a VoIP
> performance reporting standard called RTCP XR (an extension of RTCP).
> RTCP XR has defined packet loss burst metrics.  Maybe these are a good
> starting point from which to derive packet drop burst metrics.
>
> - Sean Moore
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Janardhan
> Iyengar
> Sent: Monday, September 19, 2005 6:03 PM
> To: Sally Floyd
> Cc: [e-mail]
> Subject: Re: [Tmrg-interest] the most recent version of
> draft-irtf-tmrg-metrics
>
> Sally,
>
> This is a very meaningful task, and long in waiting.
>
> I have a suggestion regarding the metric "packet drop rates". IMHO, it
> is more meaningful to have a metric, if possible, a probability
> distribution, that is rich enough to capture more than just a "rate of
> packet drops".
> I'm open to what this metric should be, but I do feel that this
> definition should be richer.
>
> At the least, a metric such as a "packet drop event rate" which captures
> the burstiness of drops could be included, in addition to "packet drop
> rate".
>
> I'm interested in hearing what others have to say.
>
> regards,
> jana
>
>
> On Mon, 29 Aug 2005, Sally Floyd wrote:
>
>> I have put a copy of draft-irtf-tmrg-metrics-01a.txt, under
>> construction for draft-irtf-tmrg-metrics-01, on the tmrg web site.  It
>
>> contains the modifications that I made today.
>> People giving feedback, or suggesting references to add, might want to
>
>> refer to this as the most version (even though it won't be submitted
>> to the internet-drafts editor until it has stabilized a bit).
>>
>> http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-01a.txt
>>
>> - Sally
>> http://www.icir.org/tmrg/
>>
>> _______________________________________________
>> Tmrg-interest mailing list
>> [e-mail]
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>>
>
> ---------------------------------------------------------------
> Janardhan R. Iyengar           http://www.cis.udel.edu/~iyengar
> Protocol Engineering Lab  --   CIS   --  University Of Delaware
> ---------------------------------------------------------------
>
> _______________________________________________
> Tmrg-interest mailing list
> [e-mail]
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>
>
>
>
> --__--__--
>
> Message: 3
> Date: Tue, 20 Sep 2005 09:28:51 -0400
> From: "Armando L. Caro, Jr." <[e-mail]>
> To: "Moore, Sean \(Sean\)" <[e-mail]>
> CC: [e-mail]
> Subject: Re: [Tmrg-interest] the most recent version of
> draft-irtf-tmrg-metrics
>
> Moore, Sean (Sean) wrote:
>>
>> When computing quality measures for VoIP flows, a similar issue arises
>> in which the average packet loss rate doesn't capture the quality
>> problems that arise from bursty packet loss.  RFC 3611 describes a VoIP
>> performance reporting standard called RTCP XR (an extension of RTCP).
>> RTCP XR has defined packet loss burst metrics.  Maybe these are a good
>> starting point from which to derive packet drop burst metrics.
>
> Those metrics seem very useful. However, I wonder if for TCP/SCTP
> traffic, burst duration and gap duration should be measured in the
> number of packets instead of absolute time. Also, burst density and gap
> density (as specified in that RFC) are calculated since the beginning of
> a flow. For long lived flows, this metric will not respond quickly
> enough to more recent burst events. I think the densities should be
> calculated over some moving window of time, but I don't know how large
> or dynamic the window should be.
>
> --
> Armando
> www.armandocaro.net
>
> --__--__--
>
> Message: 4
> Subject: RE: [Tmrg-interest] the most recent version of
> draft-irtf-tmrg-metrics
> Date: Tue, 20 Sep 2005 10:02:50 -0400
> From: "Moore, Sean \(Sean\)" <[e-mail]>
> To: "Armando L. Caro, Jr." <[e-mail]>
> Cc: <[e-mail]>
>
> This makes sense.
>
> I should probably be more clear about my suggestion that "Maybe these
> are a good starting point from which to derive packet drop burst
> metrics."  Overall, the burst metrics for UDP flows sourced by inelastic
> applications such as voice, which is the target of RTCP XR, and the
> burst-metrics for TCP-mediated flows will be different.  But we should
> look for areas of overlap and then be consistent with RFC 3611 in the
> overlapping areas, and derive the appropriate extensions to cover the
> non-overlapping areas.  It looks like Armando has already identified
> some possible extensions.
>
> Armando touched on another point that I think we need to explore
> further.  I believe much of the congestion control research and
> literature is focused on environments in which a large share of the
> traffic is composed of long-lived flows.  My personal definition of a
> long-lived flow is one that transitions out of the slow-start phase into
> the congestion avoidance phase.  My practical definition of a long-lived
> flow is that the associated file needs to be about 40Kbytes in size
> (this heuristic is based on  default Windows wmax values of 12 packets,
> an Ethernet MTU of 1500 bytes, and T1 access).  A lot of (most?)
> TCP-mediated traffic today is web-based, and since a typical web page
> results in multiple TCP connections, a typical underlying file size is
> less than 40Kbyte.  The inferrence is that it is likely that a large
> share (most) of the TCP-mediated traffic in a network is sourced by
> flows that never make it out of slow-start.
>
> In such an environment, do our typical assumptions and solutions for
> fair sharing hold up?  Does anyone know of any literature on this
> subject?  Does this have any impact on our proposed evaluation metrics?
>
> - Sean
>
> -----Original Message-----
> From: Armando L. Caro, Jr. [mailto:[e-mail]]
> Sent: Tuesday, September 20, 2005 9:29 AM
> To: Moore, Sean (Sean)
> Cc: [e-mail]
> Subject: Re: [Tmrg-interest] the most recent version of
> draft-irtf-tmrg-metrics
>
> Moore, Sean (Sean) wrote:
>>
>> When computing quality measures for VoIP flows, a similar issue arises
>
>> in which the average packet loss rate doesn't capture the quality
>> problems that arise from bursty packet loss.  RFC 3611 describes a
>> VoIP performance reporting standard called RTCP XR (an extension of
> RTCP).
>> RTCP XR has defined packet loss burst metrics.  Maybe these are a good
>
>> starting point from which to derive packet drop burst metrics.
>
> Those metrics seem very useful. However, I wonder if for TCP/SCTP
> traffic, burst duration and gap duration should be measured in the
> number of packets instead of absolute time. Also, burst density and gap
> density (as specified in that RFC) are calculated since the beginning of
> a flow. For long lived flows, this metric will not respond quickly
> enough to more recent burst events. I think the densities should be
> calculated over some moving window of time, but I don't know how large
> or dynamic the window should be.
>
> --
> Armando
> www.armandocaro.net
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> Tmrg-interest mailing list
> [e-mail]
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>
>
> End of Tmrg-interest Digest
>