- Test - lists.nanog.org

buffer bloat and packet pacing
by Saku Ytti 09 Sep '15

09 Sep '15

Hey, In past few years there's been lot of talk about reducing buffer depths, and many seem to think vendors are throwing memory on the chips for the fun of it. If we look at some particularly pathological case. Let's assume sender is CDN network with 40GE connected server and receiver is 10GE connected. There is 300ms latency between them. 10Gbps * 300ms = 375MB, is the window size the client wants to be able to fill its pipe to the 40GE sender. However TCP does not normally pace packets inside the window, so 40GE server will flood the window as fast as it can, instead of limiting itself to 10Gbps, optimally it'll send at linerate. While receiver can only serialise them 10GE out, causing majority of that 375MB ending up in the sender side switch/router buffers. If we can't buffer that, then the receiver cannot receive at 10Gbps, as window size will shrink. Is this a problem? What rate should you be able to expect to get and at what latency? Usually contracts to customers won't have any limitations on bandwidth achievable on given latency and writing such down might make you appear inferior to your competitor. Perhaps this is unrealistic case, however if you run the numbers in much less pathological cases, you'll still end up having much larger buffer needs than large number of switch chips out there have. Some new ones, like JNPR QFX10k and Broadcom Jericho come with much larger buffers than predecessors, and will be able to deal with what I hope are most practical cases. Linux actually these days does have bandwidth estimator for TCP sessions, but it's not used by default for anything, it's just for consumption for other layers so they can do something about it. And I believe in 'tc' you can use these to cause packet pacing inside a window. QUIC and MinimaLT, AFAIK, do bandwidth estimation and packet pacing by default. In perfect world, we'd be done now. Receiver side switch can do with very small buffers, few packets should suffice. However, if network itself is congested, the bandwidth estimation keeps sinking, and these well-behaved streams are losing to the aggressive TCP streams, and you'll end up having 0bps estimations. So perhaps the bandwidth estimator should be application aware, and never report lower estimate than what is practical for given application, so that it could compete fairly with aggressive streams, up-to required rate. Information I'd love to have, is how large window sizes do TCP sessions peak at, in real network? Some CDN network must be collecting these stats. I'd love to see rough statistics. <1% go over 100MB? 2% between 50MB-100MB? ... few large brackets of distribution of window sizes by some CDN offering content download (GGC, OpenConnect are not interesting, as they won't send large files). Also, are some CDN's already implementing packet pacing inside window? If so, how? Do they have lower limit to it? Some related URLs: https://lwn.net/Articles/645115/ https://lwn.net/Articles/564978/ http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-6.pdf http://www.ietf.org/proceedings/84/slides/slides-84-iccrg-2.pdf -- ++ytti

12 16

Cisco ASR9K G.8032 ERP configuration and experiences
by Florian Figula 09 Sep '15

09 Sep '15

Maybe someone having some experiences with Cisco ASR9K and ERP (G.8032)? I have configured a pair of two ASR9K for a customer. The other side is a pair of Huawei Switch. The Ring seems to work fine. We have simulated link fault and protection switch occurred but on traffic test we were not able to send traffic from one ASR9K to the other one. Both ASR9K are configured equally. For test I would also like to connect a Cisco Catalyst with trunk configuration via interface GigaBitEthernet0/0/1/7, QinQ should be possible. I think I also have to increase the MTU size on the interfaces. Next and last question, will I be able to send L3 traffic through one of the VLANs, if I will create a bvi interface and configure this under the bridge domain? ethernet ring g8032 profile PROFILE-XXX timer wtr 1 timer guard 2000 timer hold-off 0 ! interface GigabitEthernet0/0/1/7.1700 l2transport description Catalyst Trunk encapsulation dot1q 1700-1798 ! interface GigabitEthernet0/0/1/8 description "Huawei" ! interface GigabitEthernet0/0/1/8.1700 l2transport description Data encapsulation dot1q 1700-1798 ! interface GigabitEthernet0/0/1/8.1799 l2transport description APS encapsulation dot1q 1799 ! interface GigabitEthernet0/0/1/9 description "ASR9K" ! interface GigabitEthernet0/0/1/9.1700 l2transport description Data encapsulation dot1q 1700-1798 ! interface GigabitEthernet0/0/1/9.1799 l2transport description APS encapsulation dot1q 1799 ! l2vpn ethernet ring g8032 XXX port0 interface GigabitEthernet0/0/1/8 monitor interface GigabitEthernet0/0/1/8.1799 ! port1 interface GigabitEthernet0/0/1/9 monitor interface GigabitEthernet0/0/1/9.1799 ! instance 1 description XXX profile PROFILE-XXX inclusion-list vlan-ids 1700-1799 aps-channel level 7 port0 interface GigabitEthernet0/0/1/8.1799 port1 interface GigabitEthernet0/0/1/9.1799 ! ! ! bridge group G8032-XXX bridge-domain G8032-XXX-APS interface GigabitEthernet0/0/1/8.1799 ! interface GigabitEthernet0/0/1/9.1799 ! ! bridge-domain G8032-XXX-DATA interface GigabitEthernet0/0/1/7.1700 ! interface GigabitEthernet0/0/1/8.1700 ! interface GigabitEthernet0/0/1/9.1700 !

1 0

Re: internet visualization
by Larry Sheldon 09 Sep '15

09 Sep '15

On 9/8/2015 21:05, Joly MacFie wrote: > 3/10 for spelling > >> adjancencies > > or is that a thing? http://www.thefreedictionary.com/adjacencies -- sed quis custodiet ipsos custodes? (Juvenal)

3 2

Any Tool to replace Peakflow CP
by Aluisio da Silva 08 Sep '15

08 Sep '15

Hello, Does anyone here have a suggestion for a tool to replace Peakflow CP from Arbor Networks? Please if possible you would like hear some suggestions. Thanks. Aluísio da Silva Coordenação de Planejamento e Engenharia CTBC (34) 3256-2471 (34) 9976-0471 www.ctbc.com.br Esta mensagem,incluindo seus anexos,pode conter informação confidencial e/ou privilegiada,sendo de uso exclusivo dos destinatários. Seu conteúdo não deve ser revelado.Caso você não seja o destinatário autorizado a receber esta mensagem,não poderá usar,copiar ou divulgar as informações nela contidas ou tomar qualquer ação baseada nesse e-mail,por favor,comunique ao remetente e a elimine imediatamente.Não nos responsabilizamos por opiniões e/ou declarações veiculadas por e-mail não ficando obrigada ao cumprimento de qualquer condição constante deste instrumento. This message,including its attachments,contains and/or may contain confidential and privileged information.If you are not the person authorized to receive this message,you may not use,copy or disclose the information contained therein or take any action based on this information.If this message is received by mistake,please notify the sender by immediately replying to this email and deleting its files.We appreciate your cooperation.

6 7

Contact for AS701/Verizon
by Fabien VINCENT 08 Sep '15

08 Sep '15

Dear List, If someone reads my email from Verizon/AS701, we are looking for an internal contact in order to check opportunities/facilities regarding transit/PNI. Thanks in advance for any help ;) Regards, Fabien VINCENT

2 1

internet visualization
by Jared Mauch 08 Sep '15

08 Sep '15

OT: hit delete, or shameless plug disclaimer one of my colleagues just posted this visualiation of the internet from the as_path view of 2914. if you are on a mobile, you have to physically move your device around. http://as2914.net/ If you love it, send Job your accolades. If you hate it, see above disclaimer. If in a country with a holiday on monday, enjoy it safely. - Jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

13 13

Re: Extraneous "legal" babble--and my reaction to it.
by Scott Weeks 08 Sep '15

08 Sep '15

--- rdrake(a)direcpath.com wrote: From: Robert Drake <rdrake(a)direcpath.com> Maybe people could adopt an unofficial-official end-of-signature flag. Then you could have procmail strip everything after the flag: ----------------------------------------- It could be much easier. Folks that care about the mailing list rules, want to be courteous to list folks and want to use their company email, rather than one that inserts no disclaimer, could put 15 lines of blank as part of their signature. This would force all the crap far enough down the page that it wouldn't be bothersome. scott

3 2

Re: Extraneous "legal" babble--and my reaction to it.
by Scott Weeks 06 Sep '15

06 Sep '15

--- larrysheldon(a)cox.net wrote: From: Larry Sheldon <larrysheldon(a)cox.net> On 9/6/2015 14:18, Scott Weeks wrote: > --- rdrake(a)direcpath.com wrote: > From: Robert Drake <rdrake(a)direcpath.com> > > Maybe people could adopt an unofficial-official > end-of-signature flag. Then you could have > procmail strip everything after the flag: > ----------------------------------------- > > It could be much easier. Folks that care about the > mailing list rules, want to be courteous to list > folks and want to use their company email, rather > than one that inserts no disclaimer, could put 15 > lines of blank as part of their signature. This > would force all the crap far enough down the page > that it wouldn't be bothersome. Since nobody uses Telebit Trailblazers anymore--that is probably not a bad idea. ------------------------------------------- https://en.wikipedia.org/wiki/The_Times_They_Are_a-Changin'_%28song%29 :-) scott

1 0

Re: Software Defined Networking
by Larry Sheldon 06 Sep '15

06 Sep '15

On 9/4/2015 09:40, Rod Beck wrote: > Can anyone provide references on this top so I can educate myself? > > This e-mail and any attachments thereto is intended only for use by > the addressee(s) named herein and may be proprietary and/or legally > privileged. If you are not the intended recipient of this e-mail, you > are hereby notified that any dissemination, distribution or copying > of this email, and any attachments thereto, without the prior written > permission of the sender is strictly prohibited. If you receive this > e-mail in error, please immediately telephone or e-mail the sender > and permanently delete the original copy and any copy of this e-mail, > and any printout thereof. All documents, contracts or agreements > referred or attached to this e-mail are SUBJECT TO CONTRACT. The > contents of an attachment to this e-mail may contain software viruses > that could damage your own computer system. While Hibernia Networks > has taken every reasonable precaution to minimize this risk, we > cannot accept liability for any damage that you sustain as a result > of software viruses. You should carry out your own virus checks > before opening any attachment. > All of that for 11 1/2 words? Ineducable. -- sed quis custodiet ipsos custodes? (Juvenal)

6 5

Re: Extraneous "legal" babble--and my reaction to it.
by Larry Sheldon 06 Sep '15

06 Sep '15

On 9/6/2015 14:18, Scott Weeks wrote: > > > --- rdrake(a)direcpath.com wrote: > From: Robert Drake <rdrake(a)direcpath.com> > > Maybe people could adopt an unofficial-official > end-of-signature flag. Then you could have > procmail strip everything after the flag: > ----------------------------------------- > > > It could be much easier. Folks that care about the > mailing list rules, want to be courteous to list > folks and want to use their company email, rather > than one that inserts no disclaimer, could put 15 > lines of blank as part of their signature. This > would force all the crap far enough down the page > that it wouldn't be bothersome. Since nobody uses Telebit Trailblazers anymore--that is probably not a bad idea. -- sed quis custodiet ipsos custodes? (Juvenal)

1 0