Re: Goodput Definition

Hi Al,

My recollection is that this was keyed off the definition for forwarding
rate in RFC 2285 section 3.6.1, which mentions both ingress and egress
sides of the DUT/SUT.

The RFC 2285 definition explicitly does not determine whether drops
exist between ingress and egress, hence this clarification.

I'd agree that frames leaving an egress interface by definition are not
lost. In this context, "lost" refers only to those drops that should be
charged to the DUT/SUT.

dn


On 1/7/15 2:15 PM, MORTON, ALFRED C (AL) wrote:
> BMWG,
> 
> I was asked to review a draft in the AQM working group 
> which folks in BMWG may find interesting:
> https://tools.ietf.org/html/draft-ietf-aqm-eval-guidelines-00
> 
> At the moment, I'm looking at their metric descriptions
> for Flow Completion time and Goodput.  These two metrics
> have a third factor in their relationship: how much data was sent.
> 
> Flow Completion Time = (original data volume, bits) / (Goodput, bits/s)
> 
> BMWG has a definition of Goodput in RFC 2647:
> http://tools.ietf.org/html/rfc2647#section-3.17
> 
>    Definition:
>      The number of bits per unit of time forwarded to the correct
>      destination interface of the DUT/SUT, minus any bits lost or
>      retransmitted.
> 
> I understand why retransmitted bits are removed, but bits forwarded
> to the "correct destination interface" seem not to be lost.
> 
> I wonder if author David Newman or anyone else can recollect why
> lost bits must be removed, and where they were thought to be lost?
> 
> regards,
> Al
> 
> 
>  
> _______________________________________________
> bmwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bmwg
>