Subject: [bmwg] Goodput Definition

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 7 Jan 2015 17:15:22 -0500

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

---

From: David Newman <[email-masked]>
Date: Wed, 07 Jan 2015 15:19:26 -0800

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 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg
>