General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: grenville armitage <garmitage@swin.edu.au>
Cc: bloat@lists.bufferbloat.net, aqm@ietf.org
Subject: Re: [Bloat] [aqm]  pie, codel, fq_pie, fq_codel tech report
Date: Wed, 3 Aug 2016 19:13:33 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1608031906350.2015@nftneq.ynat.uz> (raw)
In-Reply-To: <57A28F9D.8060506@swin.edu.au>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1574 bytes --]

On Thu, 4 Aug 2016, grenville armitage wrote:

> Kathy, Dave,
>
> Thanks for the +ve comments!
>
> On 08/04/2016 03:03, Kathleen Nichols wrote:
>> Nicely laid out and reported, but I have a question for the authors. At the
>> top of section II. D. it says:
>> "Instantaneous’ throughput is an approximation derived
>> from the actual bytes transferred during constant windows
>> of time."
>>
>> Is the "actual bytes transferred" the sum of the packet sizes through
>> the link or is it the actual advance in sequence number bytes?
>
> Simplistic sum of the IP payload lengths per unit time as seen at the 
> destination's NIC.  (We took the line of least resistance for this tech 
> report. But yes, the advance of sequence num. per unit time would be a more 
> precise estimate of the useful flow of bytes as experienced by the 
> application.)

I would argue that bytes seen by the wire (or any router in the middle) is a far 
more useful thing to track than what the application sees.

If one application is layered inside 5 different VPNs or other encapsulation, 
while another is native on the wire, we care about the fairness of how the wire 
is used.

If we have something like ATM where transmissions are in quantums, we need to 
take this into account.

If we have something like wifi where a transmit slot is X overhead + Y*bytes 
(where 2-3K * Y = X or worse), if you don't take the overhead into account and 
just look at the application level data bytes passed you end up with such a 
distorted picture of what's going on that it's almost useless.

David Lang

  reply	other threads:[~2016-08-04  2:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-03 13:37 [Bloat] " Dave Täht
2016-08-03 17:03 ` Kathleen Nichols
2016-08-04  0:43   ` [Bloat] [aqm] " grenville armitage
2016-08-04  2:13     ` David Lang [this message]
2016-08-04 15:29       ` Kathleen Nichols

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1608031906350.2015@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=aqm@ietf.org \
    --cc=bloat@lists.bufferbloat.net \
    --cc=garmitage@swin.edu.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox