[Bloat] some experiments with downstream queue delay

[Bloat] some experiments with downstream queue delay

[Kathleen Nichols]

Pollere has been working on passive monitoring methods, in particular on
monitoring
delay. This has something of a slog, but whenever there is data, it's
pretty fun. I've
been running our prototype in my home network and wrote up the delay
results in a note:

http://pollere.net/Pdfdocs/FunWithTSDE.pdf

in case anyone would like a look. Please let me know of any
misconceptions in the note.

	Kathie

[Bloat] DualPI2 qdisc implementation available for Linux

[De Schepper, Koen (Nokia - BE)]

Hi all,

For those who missed the L4S BoF, the PI2 AQM with DualQ option is available on the following git: https://github.com/olgabo/dualpi2

PI2 (PI Improved with a Square) is a simplification of PIE (PI Enhanced) with the advantage of also supporting L4S congestion controls (like DCTCP). PI2 controls by default a single queue, with a common target (default 20ms). To get the most out of the L4S traffic you need a second L4S queue and a coupled AQM. PI2 supports this by specifying the "dualq" option. The L4S queue is having an immediate step ECN marker at 1ms, while the classic queue still has the 20ms target (with mark/drop coupled back to both L4S and Classic).

Note that PI2 supports DCTCP, but DCTCP is not the target to be used on the internet. The TCP-Prague requirements (https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-02#appendix-A) defines what is needed to have an end-system CC implementation which behaves similar to what FQ-X achieves in the network. FQ-X is a way the network can correct the behavior of classic TCP CCs, TCP-Prague is the end-system alternative that keeps the network simple and transport layer independent.

Feel free to try it out, and join in developing a TCP CC that meets the TCP-Prague requirements.

Regards,
Koen.

Re: [Bloat] DualPI2 qdisc implementation available for Linux

[Stephen Hemminger]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

Why not submit it upstream where it can get more review and will get picked
up by more users?


On Fri, Jul 29, 2016 at 2:08 AM, De Schepper, Koen (Nokia - BE) <
koen.de_schepper@nokia-bell-labs.com> wrote:

> Hi all,
>
> For those who missed the L4S BoF, the PI2 AQM with DualQ option is
> available on the following git: https://github.com/olgabo/dualpi2
>
> PI2 (PI Improved with a Square) is a simplification of PIE (PI Enhanced)
> with the advantage of also supporting L4S congestion controls (like DCTCP).
> PI2 controls by default a single queue, with a common target (default
> 20ms). To get the most out of the L4S traffic you need a second L4S queue
> and a coupled AQM. PI2 supports this by specifying the "dualq" option. The
> L4S queue is having an immediate step ECN marker at 1ms, while the classic
> queue still has the 20ms target (with mark/drop coupled back to both L4S
> and Classic).
>
> Note that PI2 supports DCTCP, but DCTCP is not the target to be used on
> the internet. The TCP-Prague requirements (https://tools.ietf.org/html/
> draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-02#appendix-A) defines
> what is needed to have an end-system CC implementation which behaves
> similar to what FQ-X achieves in the network. FQ-X is a way the network can
> correct the behavior of classic TCP CCs, TCP-Prague is the end-system
> alternative that keeps the network simple and transport layer independent.
>
> Feel free to try it out, and join in developing a TCP CC that meets the
> TCP-Prague requirements.
>
> Regards,
> Koen.
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 2453 bytes --]