* [Bloat] some experiments with downstream queue delay
@ 2016-07-13 15:47 Kathleen Nichols
2016-07-29 9:08 ` [Bloat] DualPI2 qdisc implementation available for Linux De Schepper, Koen (Nokia - BE)
0 siblings, 1 reply; 5+ messages in thread
From: Kathleen Nichols @ 2016-07-13 15:47 UTC (permalink / raw)
To: bloat
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bloat] DualPI2 qdisc implementation available for Linux
2016-07-13 15:47 [Bloat] some experiments with downstream queue delay Kathleen Nichols
@ 2016-07-29 9:08 ` De Schepper, Koen (Nokia - BE)
2016-10-25 5:12 ` Stephen Hemminger
0 siblings, 1 reply; 5+ messages in thread
From: De Schepper, Koen (Nokia - BE) @ 2016-07-29 9:08 UTC (permalink / raw)
To: bloat, TCP Prague List
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] DualPI2 qdisc implementation available for Linux
2016-07-29 9:08 ` [Bloat] DualPI2 qdisc implementation available for Linux De Schepper, Koen (Nokia - BE)
@ 2016-10-25 5:12 ` Stephen Hemminger
0 siblings, 0 replies; 5+ messages in thread
From: Stephen Hemminger @ 2016-10-25 5:12 UTC (permalink / raw)
To: De Schepper, Koen (Nokia - BE); +Cc: bloat, TCP Prague List
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] DualPI2 qdisc implementation available for Linux
2016-08-03 9:36 De Schepper, Koen (Nokia - BE)
@ 2016-08-10 9:36 ` Dave Täht
0 siblings, 0 replies; 5+ messages in thread
From: Dave Täht @ 2016-08-10 9:36 UTC (permalink / raw)
To: bloat
I will take a look at this next week. Thank you for posting the url! It
has always been my hope that pointers to aqm related codebases ended up
on a wiki somewhere. I am behind on code review of some ns3 codebases,
also, if someone wants to evaluate those, see:
https://codereview.appspot.com/293290043/
On 8/3/16 11:36 AM, De Schepper, Koen (Nokia - BE) wrote:
> (reposted as the previous did not get through due to changed email address)
>
> 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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bloat] DualPI2 qdisc implementation available for Linux
@ 2016-08-03 9:36 De Schepper, Koen (Nokia - BE)
2016-08-10 9:36 ` Dave Täht
0 siblings, 1 reply; 5+ messages in thread
From: De Schepper, Koen (Nokia - BE) @ 2016-08-03 9:36 UTC (permalink / raw)
To: bloat, aqm
(reposted as the previous did not get through due to changed email address)
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-25 5:12 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-13 15:47 [Bloat] some experiments with downstream queue delay Kathleen Nichols
2016-07-29 9:08 ` [Bloat] DualPI2 qdisc implementation available for Linux De Schepper, Koen (Nokia - BE)
2016-10-25 5:12 ` Stephen Hemminger
2016-08-03 9:36 De Schepper, Koen (Nokia - BE)
2016-08-10 9:36 ` Dave Täht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox