- NANOG - lists.nanog.org

RE: genuity - any good?
by Kris Foster 12 Apr '02

12 Apr '02

> reasonable route for your prefixes. According to one of > their top people, > prefix-lists were unreliable new technology. We gave up and > canceled the > circuit. > Genuity does use prefix lists (at least now). And, in my experiences with them is extremely fast in their turn around time to update these. Kris

1 0

re:Yahoo.com
by Joe Blanchard 12 Apr '02

12 Apr '02

Nevermind, now things seem back to normal. -Joe Blanchard

3 2

Yahoo.com
by Joe Blanchard 12 Apr '02

12 Apr '02

Anyone else seeing odd behavior from yahoo.com? Certain servers there seem unresponsive (classified.yahoo.com) using http at times. Just wondering. ICMP seems to echo fine (<20ms) but pages seem not to be loading intermitantly. Just wondering, seeing this behavior from 2 diffirent nets perspective. -Joe Blanchard

1 0

RE: OT? cRTP header compression
by Mathew Lodge 11 Apr '02

11 Apr '02

At 03:19 PM 4/11/2002 -0400, Nathan Stratton wrote: >On Thu, 11 Apr 2002, Mathew Lodge wrote: >Note that turning on VAD does decrease the > > perceived voice quality a little, so whether it is worth it depends on > > where you want to make the trade-off between cost and voice quality. > >I am not a big fan of VAD in my network, customers do not like the silence >they get on the other end. Perhaps you are not using equipment that offers comfort noise generation when VAD is enabled. On a Cisco 2600/3600/5300, make sure you have comfort noise generation turned on, and the gain set to a level such that your users can hear it. > As far as packet size, you want to use the >smallest you can get away with. I use 9 or 21 ms of G.726 on my network, I >know they are odd sizes, but we run our own version of CRTP directly over >AAL5 so we want to fill the cells correctly. In a perfect world, you wouldn't bother with VAD, cRTP, longer sample sizes, expensive CODECs or any of the other technologies for optimizing bandwidth. But these are all valid technologies when bandwidth is expensive. You can increase the sample size without affecting perceived voice quality, because perceived voice quality is a step function of latency. Human listeners don't notice voice latency until it passes a threshold, when suddenly it becomes very apparent and perceived quality (measured by MOS) plummets. Various standards bodies argue about where that threshold is, but my experience to date suggests it's around the 150ms mark -- your mileage may vary. Doubling the standard Cisco voice sample size (20ms) to 40ms only adds 20ms to end-to-end latency, halves the packet rate and doubles the ratio of payload to header. Secondly, when link cost is high, it is often prohibitively expensive to buy circuits with higher data rates. And when this happens, serialization delay (the time it takes to get a packet on the wire) starts to become a major issue -- and that is directly impacted by the ratio of payload to header size. Cheers, Mathew > ><> >Nathan Stratton CTO, Exario Networks, Inc. >nathan at robotics.net nathan at exario.net >http://www.robotics.net http://www.exario.net | Mathew Lodge | mathew(a)cplane.com | | Director, Product Management | Ph: +1 408 789 4068 | | CPLANE, Inc. | http://www.cplane.com |

2 1

RE: OT? cRTP header compression
by Mathew Lodge 11 Apr '02

11 Apr '02

At 08:55 PM 4/10/2002 -0700, Pena, Antonio wrote: >I had some kind of experience doing cRTP over Cisco routers, we use Cisco >7204 & 7206 Routers on the IP Gateways and Cisco's 3600 and 5300 as VoIP >gateways, as well we had a small setup using a Cisco 2611 router on the >termination router. As well as increasing sample size (thereby increasing the payload:header ratio), the other thing to try is turning on voice activity detection (VAD, AKA silence suppression). For human conversation, this typically reduces packet rates by around 60%, enabling you to squeeze more conversations onto the link. It also has the side effect of reducing CPU utilization per call on your Cisco voice gateways. Note that turning on VAD does decrease the perceived voice quality a little, so whether it is worth it depends on where you want to make the trade-off between cost and voice quality. Also, cRTP is not CEF switched on the 5300 in 12.2, AFAIK. It was on 26xx/36xx, but 5300 architecture (and hence switching code) is different. That may have changed since I last looked 6 months ago -- best bet is to ask on the Cisco-NAS mailing list at http://www.cisco.com/warp/public/471/cisco-nas.html Cheers, Mathew >The trick is change the VoIP payload size of each packet to reduce the >packets per second in a half improving the performance over the routers, >also we are using as Cisco recommends TCP & RTP headers compression over the >circuits using only MLPPP encapsulation. > >Also please note that using cRTP and Compression you have increased the >switching delay over the circuit and for that reason you may need also to >have more processing power of the router. > >Below you can see a Cisco site where you can check the recommendations for >this setup and also based on that information I created a Bandwidth >calculator on an excel sheet, if you want it, just drop me an email, I will >send it you. > >http://www.cisco.com/warp/public/788/voice-qos/voip-mlppp.html > >http://www.cisco.com/warp/public/788/pkt-voice-general/bwidth_consume.html > >http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos >_c/fqcprt6/qcfcrtp.htm > >http://www.cisco.com/warp/public/105/compression-qos.html > > > >Bye > >Antonio J. Pena >Manager, Network Engineering > >( /_ _ _ __/_ _ >|_/(-/ (-_) /(// >Verestar, inc. >1901 Main street >Santa Monica, CA, 90405 >Phone(310)382-3300 >Direct(310)382-3409 >antonio_pena(a)verestar.com >http://www.verestar.com > > >-----Original Message----- >From: Thomas Kernen [mailto:tkernen@deckpoint.ch] >Sent: Wednesday, April 10, 2002 1:11 PM >To: nanog(a)merit.edu >Subject: OT? cRTP header compression > > > > >I'm looking for real world experience related to deploying cRTP header >compression on Cisco routers related to VoIP flows. We are trying to >evalute what type of hardware (ie: CPU power since cRTP is CEF switched >since 12.2x IIRC) is required to handle 96/192/384 VoIP calls over a >single circuit (HDLC/PPP/FR). This is related to specific overseas >circuits where the cost of the circuit is still very expensive vs the >cost for the extra hardware to handle the header compression. I'm >disregarding all QoS info at this stage. > >Cheers >Thomas

4 4

Re: Load balancing in routers
by Stephen Sprunk 11 Apr '02

11 Apr '02

Thus spake "Peter Panagakos" <ppanagakos(a)nuvo.com> > Is this still the norm? In regards to not using "no ip route-cache". > > I recall reading somewhere in Cisco documentation that in BGP > multihomed scenarios that it was the preferred method of control > on non-CEF gear. If that's still in the documentation, it's an oversight. Please see my other message on the performance effects of process switching. S

1 0

RE: OT? cRTP header compression
by Pena, Antonio 11 Apr '02

11 Apr '02

Hello Thomas I had some kind of experience doing cRTP over Cisco routers, we use Cisco 7204 & 7206 Routers on the IP Gateways and Cisco's 3600 and 5300 as VoIP gateways, as well we had a small setup using a Cisco 2611 router on the termination router. The trick is change the VoIP payload size of each packet to reduce the packets per second in a half improving the performance over the routers, also we are using as Cisco recommends TCP & RTP headers compression over the circuits using only MLPPP encapsulation. Also please note that using cRTP and Compression you have increased the switching delay over the circuit and for that reason you may need also to have more processing power of the router. Below you can see a Cisco site where you can check the recommendations for this setup and also based on that information I created a Bandwidth calculator on an excel sheet, if you want it, just drop me an email, I will send it you. http://www.cisco.com/warp/public/788/voice-qos/voip-mlppp.html http://www.cisco.com/warp/public/788/pkt-voice-general/bwidth_consume.html http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos _c/fqcprt6/qcfcrtp.htm http://www.cisco.com/warp/public/105/compression-qos.html Bye Antonio J. Pena Manager, Network Engineering ( /_ _ _ __/_ _ |_/(-/ (-_) /(// Verestar, inc. 1901 Main street Santa Monica, CA, 90405 Phone(310)382-3300 Direct(310)382-3409 antonio_pena(a)verestar.com http://www.verestar.com -----Original Message----- From: Thomas Kernen [mailto:tkernen@deckpoint.ch] Sent: Wednesday, April 10, 2002 1:11 PM To: nanog(a)merit.edu Subject: OT? cRTP header compression I'm looking for real world experience related to deploying cRTP header compression on Cisco routers related to VoIP flows. We are trying to evalute what type of hardware (ie: CPU power since cRTP is CEF switched since 12.2x IIRC) is required to handle 96/192/384 VoIP calls over a single circuit (HDLC/PPP/FR). This is related to specific overseas circuits where the cost of the circuit is still very expensive vs the cost for the extra hardware to handle the header compression. I'm disregarding all QoS info at this stage. Cheers Thomas

2 1

Re: packet reordering at exchange points
by Paul Vixie 11 Apr '02

11 Apr '02

> Hmmmm. You're right. I lost sight of the original thread... > GigE inter-switch trunking at PAIX. In that case, congestion > _should_ be low, and there shouldn't be much queue depth. indeed, this is the case. we keep a lot of headroom on those trunks. > But this _does_ bank on current "real world" behavior. If > endpoints ever approach GigE speeds (of course requiring "low > enough" latency and "big enough" windows)... > > Then again, last mile is so slow that we're probably a ways away > from that happening. my expectation is that when the last mile goes to 622Mb/s or 1000Mb/s, exchange points will all be operating at 10Gb/s, and interswitch trunks at exchange points will be multiples of 10Gb/s. > Of course, I'd hope that individual heavy pairs would establish > private interconnects instead of using public switch fabric, but > I know that's not always { an option | done | ... }. individual heavy pairs do this, but as a long term response to growth, not as a short term response to congestion. in the short term, the exchange point switch can't present congestion. it's just not on the table at all.

10 20

Sheilded Cat-5E Ground Loop - Myth or Reality?
by Christopher K. Neitzert 11 Apr '02

11 Apr '02

Hi I'm in the process of managing cabling for a large install (500-ish runs) and a vendor came to me with a story about the creation of ground loops in running sheilded+gounded cat-5e in large installations. Does anyone have any experiences they would like to share regarding this? thanks christopher Christopher K. Neitzert / 0xC10D222F / chris(a)neitzert.com

6 9

NANOG costs
by Paul Revere 11 Apr '02

11 Apr '02

We used to pay $150 or so to attend NANOG conferences. Why are we charged $300 now? Where is our $150,000+ going? Inflation? Are we paying for the salaries and RIPE attendance of MERIT employees, and to what tune? Conference space is free or greatly subsidized in return for room blocks. Connectivity, terminal rooms (who uses those anyway?), operational support, and hardware are all no-cost items to MERIT. Continental breakfast costs $8k to sponsor. Morning or afternoon break costs $6k. Lunch or dinner, $18k. Beer and Gear is $6k per vendor, and has been booked solid for the last ten NANOG conferences. That's a lot of money right there. So what are we actually paying for, the t-shirts? Are we subsidizing other MERIT money losers? With IT and engineering budgets shrinking, and unemployment on the rise, should MERIT be obligated to share with us a more detailed financial accounting, or is this none of our business? __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

11 12