- NANOG - lists.nanog.org

red [was Re: Cisco PPP DS-3 limitations - 42.9Mbpbs?]
by smd＠clock.org 20 Feb '02

20 Feb '02

randy bush writes: | you can turn on [x]red. it will make a better choice of which packets | to drop. but packets will still be dropped [0]. fsvo "better". red drops packets randomly, a little earlier than packets will be tail-dropped by being unable to find buffer space in a queue. in most cases, tail-drop is worst for TCP connections in slow-start, and leads to such fun things as web-page-slowdown-syndrome, or ssh-stall-syndrome, with the attendant hitting of the "reload" button or frustrated banging on the keyboard trying to get one's keys to echo back, or trying to unstick the page of text being sent to /dev/tty on the remote end. "r" for random: this spreads out loss randomly, and in most cases, this means that several different TCPs each observe a single lost segment, which is quickly detected and causes an attendant slow-down, but not a stall. "e" for early: we have to keep the queue from filling, because that leads to tail-drop, so we have to drop packets when we could really send them. there is no way around this -- in virtually any implementation, the mechanism to turn on red can be translated into more fifo-queue space. the trade-off (early random dropping) is usually worth it. there are some corner cases where there is insufficient ability to spread drops across enough flows, where resulting behaviour can be alot like tail-drop (a huge difference between fast input speed and slow output speed, with only a few bulk-transfer flows), but these cases are rare, particularly where average_segment_size / bottleneck_kbps <= 0.4, with the 0.4 being a historical minimum target for queueing in the presence of flows which experience long RTTs (like ones across oceans). in general, you don't have to worry about that, though. | you can increase buffers blah blah blah. but twenty tomatoes will still | not fit in a fifteen tomato can. yup, the trick is to deploy a red control law that drops just before tail-dropping would start, so we don't lose packets unnecessarily, yet early enough before tail-dropping would start that the senders have time to back off in response to the detected lost segment, which is driven by the RTT. drop too early, and you get an underused line. drop too late and you get tail-drop, which also gives you an underused line. drop just right, and you can keep your line very very very close to 100% for sustained periods of time (hours!), assuming a large enough set of TCP flows that random dropping spreads the early dropping across different flows. | [0] - corollary: qos mechanisims decide which packets to drop. but isps | are paid not to drop any packets. it is impossible to get 0 drop and enjoy statistical multiplexing gain. statmux gain keeps the network cheap enough to use. red minimizes the liklihood that anyone will complain about performance during those inevitable periods when one's statistical bet goes wrong. Sean.

1 0

RE: Cisco PPP DS-3 limitations - 42.9Mbpbs?
by Goodwin, Dustin T [IT] 20 Feb '02

20 Feb '02

Assuming this utilization figure is correct the other way to milk a higher utilization out of the link is by using Random Early Detect (RED) or Weighted RED. This will eliminate jagged utilization pattern you see in fully consumed link which is caused by TCP window synchronization. RED will give you a smoother utilization line that is closer to maximum theoretical throughput of the link. - Dustin - -----Original Message----- From: Ehud Gavron [mailto:gavron@wetwork.net] Sent: Wednesday, February 20, 2002 9:24 AM To: nanog(a)merit.edu Cc: GAVRON(a)Opus1.COM Subject: Cisco PPP DS-3 limitations - 42.9Mbpbs? At a recent consulting opportunity, a client was only getting 40.9Mbps on their DS-3 (clearchannel DS3 over OC12 to the IP provider). (PA-2T3 to PA-2T3, unloaded CPU, drops occur when peak octets out per sec/8=40.9M) The client asked us why 40.9 was less than 44.210. The IP provider indicated that "Cisco told us the maximum theoretical rate of an interface doing DS-3 with PPP encapsulation is 42.9." I can't find documentation to the 42.9. I can't find documentation that indicates that the PPP overhead is somehow magically excluded from the IfOctetsIn and Out... I can't find documentation as to why 40.9 is the observed rate. Frankly, all my DS-3s (HDLC encap) go up to 44.210, so I was hoping I could share in the collective wisdom of NANOG readers who have DS-3s to IP providers, and can provide real observed feedback. Please reply privately. Please let me know privately if you want a summary. Thanks! Ehud Gavron gavron(a)wetwork.net

1 0

Reviewer Request: "The Art of Peering - The Peering Playbook"
by William B. Norton 20 Feb '02

20 Feb '02

Hi folks - I walked about 15 ISP Network Architects and Peering Coordinators through this latest draft of the white paper "The Art of Peering : The Peering Playbook", and I now have presentable draft that I'd like to share with a slightly broader set of interested folks (preferably Network Architects and Peering Coordinators). Here is the Abstract: ------------------------------------------------------- snip ------------------------------------------------------ Internet Service Provider (ISP) Peering Coordinators were interviewed over the past few years for the "Interconnection Strategies for ISPs", "Internet Service Providers and Peering", and "A Business Case for Peering" Internet Operations Research papers. In these previous works, we documented the commonly used terminology (Peering, Transit, Transport, etc.), the motivations, the financial justifications and the process of peering. In "The Art of Peering" we build upon this foundation and present tactics that Peering Coordinators have used to obtain peering where they otherwise might not have been able to obtain peering. We have identified 17 specific maneuvers that vary from mundane to the clever, from merely deceptive to manipulative. In sum, these tactics represent the "Peering Playbook", the current "Art" of Peering. ----------------------------------------------------- snip ------------------------------------------------------- If you can help and have the inclination to read it (about 10 pages) and comment, please send me e-mail: wbn(a)equinix.com Thanks - Bill PS - Thanks to those who helped with the last paper "A Business Case for Peering". If I didn't send you the latest (version 1.3) send me e-mail and I'd be glad to email you a copy. BTW - The latest version of "Internet Service Providers and Peering" is 2.4 and that is available as well. ---------------------------------------------------------------------------- ------------------------------------------------- William B. Norton Co-Founder and Chief Technical Liaison Equinix wbn(a)equinix.com 650.315.8635

1 0

Survey of Bandwidth Services and List Pricing
by Shivkuma 20 Feb '02

20 Feb '02

Dear NANOGers, I would like to understand trends in list-pricing and bandwidth service offerings by various ISPs, as part of an academic study on economic models of ISPs. I have three short questions in this survey. Kindly reply to me directly, and your information will be kept confidential, and will only be published in aggregate form (eg: average list pricing of assured-service bandwidth by tier-2 ISPs etc). Your answers will greatly help our research, and in return we will provide you a copy of our results/papers on this topic. ========================================================================= Questions: 1. Is your ISP a Tier-1, Tier-2 or Tier-3 ISP (or network-service-provider)? 2. What are the bandwidth services your ISP sells ? (eg: leased lines, frame-relay, IP CoS, Diff-serv assured service or others...) 3. What is the list pricing for these services for a median customer ? (feel free to categorize further into small-, medium-, large-, reseller- etc) ======================================================================= Thanks a lot! -Shiv === Shivkumar Kalyanaraman Associate Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI) WWW: http://www.ecse.rpi.edu/Homepages/shivkuma

1 0

Looking for ISP in Beirut
by Rishi Singh 19 Feb '02

19 Feb '02

Hello all, I'm looking for an ISP in Beirut that has 200ms or less to New York City (a tall order I know). Currently, I have a link over satellite that has too much latency for a trading application (approximately 668ms, I'm seeing). -Thanks

2 1

Controlling the impact of BGP policy changes on IP traffic
by Nick Feamster 19 Feb '02

19 Feb '02

Hello NANOG, Jennifer Rexford, Jay Borkenhagen and I have been working on developing useful traffic engineering techniques for network operators (like yourselves). Specifically, we've been trying to show how network operators can tune traffic on outbound links using BGP import policies while minimizing network instability. Since the paper we've been working on really is about how to make your lives easier, we would very much appreciate your comments on the work. We'd also enjoy learning about other types of tricks that network operators play to tune traffic flows. http://nms.lcs.mit.edu/~feamster/papers/att-tm01.{ps,pdf} Thanks! Nick ########## Nick Feamster, Jay Borkenhagen, and Jennifer Rexford, "Controlling the impact of BGP policy changes on IP traffic," AT&T Research Technical Report 011106-02, November 2001. Abstract: The Internet consists of nearly 12,000 autonomous systems (AS's) that exchange routing information using the Border Gateway Protocol (BGP). The operators of each network need to have control over the flow of traffic through the AS. However, BGP does not facilitate common traffic engineering tasks, such as balancing load across multiple links to a neighboring AS or directing traffic to a different neighbor. Solving these problems is difficult because the number of possible changes to routing policies is too large to exhaustively test all possibilities, some changes in routing policy can have an unpredictable effect on the flow of traffic, and the BGP decision process implemented by router vendors limits an operator's control over path selection.

1 0

global BGP instability
by cowie＠renesys.com 19 Feb '02

19 Feb '02

Would anyone care to give some operational insight into the surge of BGP routing instability this morning between appx 08:00 and 10:00 GMT? Turned on and off like a lightswitch, as seen from GRADUS (http://gradus.renesys.com) -- we saw cleanly correlated and sustained increases in the prefix announcement and withdrawal rates reported by all GRADUS feeds during that window. --jim p.s. By the way, we haven't seen the kind of sustained increase in "maintenance cycle" routing instability that we were expecting after the SNMP news broke. Some increase in the background noise, but nothing major overall. Good job, guys :)

3 3

Dacom contact
by David Sinn 18 Feb '02

18 Feb '02

Can someone from Dacom (AS3786) please contact me off-list? Thanks! David Sinn Senior Network Engineer Microsoft Internet Hosting Services dsinn(a)microsoft.com

1 0

Not strictly operational: maps for fiber planning?
by Timothy Brown 18 Feb '02

18 Feb '02

Can someone point me to resources for maps/GIS data (for use in fiber planning), as well as competitors to Telegeography (companies already showing data on currently laid cables)? I'm basically looking for: Companies who provide maps and mapping services with political, topographic, and GIS data Companies who provide maps of already laid out fiber routes and telecom infrastructure I'm not looking for people who can do it only in the US - I need world coverage (with drilldown to individual countries). Private emails would be preferred; i'll summarize. Thanks, Tim

1 0

RE: Call for papers - First ever NordNOG event
by Stanley, Jon 18 Feb '02

18 Feb '02

Give it a couple hours :-) -----Original Message----- From: smd(a)clock.org [mailto:smd@clock.org] Sent: Sunday, February 17, 2002 2:42 PM To: nanog(a)nanog.org Subject: Re: Call for papers - First ever NordNOG event PS: nerdnog.org doesn't work either, dammit.

2 1