[Bloat] pie, codel, fq_pie, fq_codel tech report

[Bloat] pie, codel, fq_pie, fq_codel tech report

[Dave Täht]

I am especially grateful for the full documentation of how to configure
the bsd versions of this stuff, but the rest of the report was pretty
good too.

http://caia.swin.edu.au/reports/160708A/CAIA-TR-160708A.pdf

Re: [Bloat] pie, codel, fq_pie, fq_codel tech report

[Kathleen Nichols]

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?

	thanks,
		Kathie


On 8/3/16 6:37 AM, Dave Täht wrote:
> I am especially grateful for the full documentation of how to configure
> the bsd versions of this stuff, but the rest of the report was pretty
> good too.
> 
> http://caia.swin.edu.au/reports/160708A/CAIA-TR-160708A.pdf
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> 

Re: [Bloat] [aqm] pie, codel, fq_pie, fq_codel tech report

[grenville armitage]

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.)

cheers,
gja

>
> 	thanks,
> 		Kathie
>
>
> On 8/3/16 6:37 AM, Dave Täht wrote:
>> I am especially grateful for the full documentation of how to configure
>> the bsd versions of this stuff, but the rest of the report was pretty
>> good too.
>>
>> http://caia.swin.edu.au/reports/160708A/CAIA-TR-160708A.pdf
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

-- 
Professor Grenville Armitage
Director, Centre for Advanced Internet Architectures
School of Software and Electrical Engineering
Faculty of Science, Engineering and Technology
Swinburne University of Technology, Australia
http://caia.swin.edu.au

Re: [Bloat] [aqm] pie, codel, fq_pie, fq_codel tech report

[David Lang]

[-- 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

Re: [Bloat] [aqm] pie, codel, fq_pie, fq_codel tech report

[Kathleen Nichols]

David,

It is not necessarily "either-or". Tracking the forward progress of data
sees lets you evaluate the effectiveness of the protocol, aqm,
scheduling, and any
other elements of the network. That doesn't mean other metrics can't be
tracked.

	Kathie

On 8/3/16 7:13 PM, David Lang wrote:
> 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
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>