Oops - acronym soup.
UFB = Ultrafast Broadband, delivered on fibre to the premises.
BWP = bandwidth profile, as per MEF standards.
The issue we face is that the rollout of the UFB network is subject to contracted SLAs which have very tight frame delay variation. In order to achieve the SLA target, Chorus have implemented small burst sizes on the ingress policers.
If the traffic coming from the service provider or the end user is not shaped to match the burst size then TCP throughput is reduced. Unfortunately some equipment struggles to shape the traffic with sufficiently small egress bursts to get good throughput.
It would be interesting to see if active queue management such as codel & variants improves throughput in this situation - which is sort of the reverse of the conditions that prompted its development (not enough delay rather than too much).
Jonathon.
-----Original Message-----
From: Dave Taht [mailto:dave.taht(a)gmail.com]
Sent: Tuesday, 27 January 2015 4:27 p.m.
To: Jonathon Exley
Cc: NZNOG(a)list.waikato.ac.nz
Subject: Re: [nznog] bufferbloat talk at nznog friday
On Mon, Jan 26, 2015 at 5:13 PM, Jonathon Exley
On a related note, I have been poking around in ns2 trying to see if I can simulate TCP flows over a UFB service to see the effect of different BWP burst sizes.
I don't get the latter two acronyms.
However the diffserv model in ns2 doesn't drop packets marked red, it only assigns a higher RED drop probability - not quite the behaviour I was looking for.
I think my not understanding the first part of the question leads to me not understanding this part.
Has anyone on the list played with ns2 or ns3 and looked at modelling QoS stuff?
The release candidate ns2 code containing pie, codel, fq_codel, red and variants: http://nsnam.isi.edu/nsnam/index.php/Roadmap The release candiate ns3 code incorporating codel and fq_codel: http://www.nsnam.org/wiki/AQM_enhancements Both are nearly done and could use more testers. I personally avoid ns2 (tcl. ugh.) for ns3 (python, yea!), and in neither case will a ns2 or ns3 model give you results that even remotely match the real (bufferbloated) world, unless you configure your sim to match it. (there's a pretty good test in the ns3 codebase now). How I think about "QoS" is pretty different, In terms of importance: fixing the device driver queues with techniques like BQL, then fair queueing, followed by aqm, fixing the actual device driver queues, and then and only then attempting packet prioritization of any kind. By just applying "QoS" you are trying to direct the end of the firehose whilst holding onto it next to the fire-engine.
Jonathon.
-----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Ewen McNeill Sent: Monday, 26 January 2015 8:47 a.m. To: Dave Taht; NZNOG(a)list.waikato.ac.nz Subject: Re: [nznog] bufferbloat talk at nznog friday
---8<---
And any advice on defining such operator shaping/policing policies to make them less likely to cause adverse behaviour (eg, being less sensitive to packet arrival time of the "last packet of the burst arrived 1ms too soon, so we threw it away, have a nice day" variety).
---8<---
This communication, including any attachments, is confidential and may be legally privileged. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. No confidentiality or privilege is waived or lost by any mis-transmission or error. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks