- Test - lists.nanog.org

Re: [Q] BGP filtering policies
by smd＠clock.org 10 Apr '02

10 Apr '02

| UUNet suggested that any problems encountered | as a result of this allocation could probably solved by e-mailing | any NSP whose traffic interchange with us might be negatively | affected (unlikely, to be sure, but still...), and would then | change their filter (I'm unconvinced of this scenario). Try offering some money to such NSPs -- it probably doesn't have to be much, and of course you would be receiving substantial benefit... Sean.

2 1

RE: [Q] BGP filtering policies
by smd＠clock.org 10 Apr '02

10 Apr '02

| With enough badgering most providers will accept a /24 announcement of PA | space. With a token offer to make a payment of, say, 150 dollars, you will save yourself considerable badgering time and effort. Of course, if time isn't money, or you don't believe in negotiations (think ebay...), then badger away. Sean.

1 0

RE: [Q] BGP filtering policies
by Borchers, Mark 10 Apr '02

10 Apr '02

If you'll look at this pointer to one of ARIN's pages, it lists the minimum allocation size for each CIDR block that IANA has given ARIN to manage. From what I've seen, most providers accept at least up to the prefix length that the RIR's are using, if not longer. http://www.arin.net/statistics/index.html#ipv4issued2002 Unfortunately, this doesn't help in your case. My company also has /14's from the traditional class A space. I know of only one case in two years where a customer reported a problem arising from holding a small assignment out of these blocks, which was ultimately corrected by renumbering the customer, a solution which does not scale well. Worst case, however, unless your UUNet connection goes down, you'll still be able to reach most places via your other transit and peering (since /24 is the closest thing to a "universal" allowed prefix length) and will have full reachability via UUNet. IMHO, accepting up to /24 in any of the space listed on the above URL is good service provider practice. > -----Original Message----- > From: Henry Yen [mailto:henry@AegisInfoSys.com] > Sent: Tuesday, April 09, 2002 2:11 PM > To: nanog(a)merit.edu > Subject: [Q] BGP filtering policies > > > > We were recently assigned a /22 from UUNet in conjunction with some > transit we're buying from them. The space is inside their superblock, > 65.242.0.0/14. We are concerned that our route announcement of this > block would be filtered out by some other providers, as it's not > class C/swamp space (or even class B space for that matter). > Verio's current policy, for one, indicates that this would be so. > > This is of particular concern to us as our little network encompasses > several physical partially-meshed locations, with a mix of varying > bandwidths both upstream as well as intra-location. Traffic > Engineering > is what we think is a reasonable (business) approach to address our > flexibility needs, and so we're trying to move to address > space(s) that > would be least likely to be BGP filtered. > > We've asked for a different block from UUNet but the request didn't > meet with success; UUNet suggested that any problems encountered > as a result of this allocation could probably solved by e-mailing > any NSP whose traffic interchange with us might be negatively > affected (unlikely, to be sure, but still...), and would then > change their filter (I'm unconvinced of this scenario). > > I briefly browsed the NANOG archives, and didn't see this > issue discussed > recently. Have the BGP filtering policies for "most" ISP/NSP's been > relaxed to the level of "accept /24's from class A > (ARIN-allocated) space"? > Am I mis-reading Verio's posted policy? Is there anyone from UUNet > who might choose to comment? Is there something else I'm > misunderstanding? > > -- > Henry Yen Aegis > Information Systems, Inc. > Senior Systems Programmer Hicksville, New York >

4 3

Re: packet reordering at exchange points
by Joe St Sauver 09 Apr '02

09 Apr '02

>Date: Tue, 09 Apr 2002 16:03:53 -0400 >From: Richard A Steenbergen <ras(a)e-gerbil.net> >Subject: Re: packet reordering at exchange points > >To transfer 1Gb/s across 100ms I need to be prepared to buffer at least >25MB of data. According to pricewatch, I can pick up a high density 512MB >PC133 DIMM for $70, and use $3.50 of it to catch that TCP stream. Throw in >$36 for a GigE NIC, and we're ready to go for under $40. Yeah I know thats >cheapest garbage you can get, but this is just to prove a point. :) I >might only be able to get 800Mbit across a 32bit/33mhz PCI bus, but >whatever. Of course, in reality, things like choice of NIC can matter tremendously when it comes to going even moderately fast, which is why people continue to pay a premium for high performance NICs such as those by Syskonnect. (When you see vendors touting near-gigabit throughput for inexpensive gig NICs, beware: you're probably looking at benchmarks consisting of multiple streams sent with jumbo frames between two machines connected virtually back to back rather than "real world" performance associated with a single wide area tcp flow across a 1500 byte MTU link). >The problem isn't the lack of hardware, it's a lack of good software (both >on the receiving side and probably more importantly the sending side), a >lot of bad standards coming back to bite us (1500 byte packets is about as >far from efficient as you can get), a lack of people with enough know-how >to actually build a network that can transport it all (heck they can't >even build decent networks to deliver 10Mbit/s, @Home was the closest), >and just a general lack of things for end users to do with that much >bandwidth even if they got it. In the university community, it is routine for students in residence halls to have access to switched 10 (or even switched 100 Mbps) ethernet; of course, at that point, the issue isn't a lack of things for end users to do with that much (potential) bandwidth, it is the *cost* of provisioning wide area commodity bandwidth to support the demand that that speedy local infrastructure can generate that becomes the binding constraint. And speaking of University users, if you look at Internet2's excellent weekly reports (see, for example: http://netflow.internet2.edu/weekly/20020401/#fastest ) you'll see that wide area TCP non-measurement single flows *are* occuring at and above the 100Mbps mark, at least across that (admittedly rather atypical) network infrastructure. [Maybe not as commonly as we'd all like to hope, but they are happening.] Regards, Joe

2 1

Re: Ph.D. student looking for data on network failure causes
by David L. Oppenheimer 09 Apr '02

09 Apr '02

By the way, just a clarification of my original message: the results of this study will (eventually) be published in some academic forum. I'll post to the NANOG mailing list a pointer to any results when they are available, so there's no need to email me separately to indicate your interest in the results. (Interest in providing data, on the other hand, would be most welcome!) Thanks, David > Hello network operators! I'm a Ph.D. student at UC Berkeley working for Dave > Patterson on the ROC project, which is investgiating techniques for > improving the availability and manageability of large-scale Internet > services and systems. I'm currently conducting a study of the root causes > (hardware, softare, human, etc.) and durations of failures in such systems. > To do this, I have been examining the operations trouble ticket databases > from several large-scale Internet services (of the Hotmail, eBay, Yahoo!, > etc. type). > > In doing this research, it has become apparent that for many services > (especially geographically distributed ones, e.g. those that use multiple > colocation facilities), a major cause of problems is failures of various > types in the Internet. Thus I've become interested in finding out the types > and root causes of problems in wide-area networks, e.g. within the kinds of > large-scale ASes that are administered by the folks on this list. I'm not > sure how your services track failures and problems; the problem tracking > databases at the services I've examined have been a great source of data > about problem scale, symptoms, root causes, durations, steps (and missteps!) > taken in diagnosing and fixing problems, etc. > > I'm writing to the list because I'm very interested in working with network > operators to study the causes of failures in large networks. I realize this > type of data is very sensitive to your organizations. I would be happy to > talk offline with anyone who is interested in the possibility of sharing > data, about how I've overcome the multitude of objections that have been > raised by folks I have solicited for data (protecting their customers' > privacy, securing datasets when they are not examined on the premises of the > services, anonymizing and aggregating data in reporting, etc. etc.). I'm > interested in the relative causes of failures, *not* overall availability > numbers. As a result of the precautions we've taken, several household-name > Internet services have allowed me to examine and report on the problems > their servcies have experienced. > > If you're interested in discussing the possibility of sharing access to this > kind of data about your service, please contact me. I'm willing to examine > data on the premises of your service, to anonymize it fully, to submit any > results I want to publish to your organization prior to publication, to sign > any necessary NDAs, etc. In return, I'm happy to share with you any insights > I have about the problems your service experiences, and you'll contribute to > the world's knowledge of why bad things happen to good networks. :-) > > If you're not the right person in your organization to contact with this > request, but you think your organization might be interested in > participating in this study, perhaps you could forward this email to the > appropriate person or let me know who the right person to contact in your > organization would be.

1 0

packet reordering at exchange points
by Paul Vixie 09 Apr '02

09 Apr '02

> packet reordering at MAE East was extremely common a few years ago. Does > anyone have information whether this is still happening? more to the point, does anybody still care about packet reordering at exchange points? we (paix) go through significant effort to prevent it, and interswitch trunking with round robin would be a lot easier. are we chasing an urban legend here, or would reordering still cause pain?

9 14

BGP filtering policies, UU, and you
by David Barak 09 Apr '02

09 Apr '02

Hi Henry et al, There's no real problem with your current space. Assume for the minute that each of your offices has a UU T1. You announce the chunks of your /22 through your various T1s, and that announcement (along with the UU/14) is passed along to UU customers and peers. Verio will ignore the /22, but will direct traffic to UU because they will accept the /14. so no problem there. The only possible issue is this: assume one T1 to UU and one to <non-Verio provider>. UU T1 goes down, therefore /22 withdrawn there, /22 announcement through <provider> becomes only route. Verio ignores this, and directs traffic to UU (via the /14), and UU will then direct traffic to <provider> because UU has very liberal routing policies. So in the worst case, you could get some sub-optimal routing, but nothing particularly bad, and Verio is the only substantive ISP who still uses these filters (AFAIK). The bigger issue in that case would be getting the UU line up faster :) -David Barak "Quis custodes ipsos custodiet?" - Juvenal Henry Yen wrote: We were recently assigned a /22 from UUNet in conjunction with some transit we're buying from them. The space is inside their superblock, 65.242.0.0/14. We are concerned that our route announcement of this block would be filtered out by some other providers, as it's not class C/swamp space (or even class B space for that matter). Verio's current policy, for one, indicates that this would be so. This is of particular concern to us as our little network encompasses several physical partially-meshed locations, with a mix of varying bandwidths both upstream as well as intra-location. Traffic Engineering is what we think is a reasonable (business) approach to address our flexibility needs, and so we're trying to move to address space(s) that would be least likely to be BGP filtered. We've asked for a different block from UUNet but the request didn't meet with success; UUNet suggested that any problems encountered as a result of this allocation could probably solved by e-mailing any NSP whose traffic interchange with us might be negatively affected (unlikely, to be sure, but still...), and would then change their filter (I'm unconvinced of this scenario). I briefly browsed the NANOG archives, and didn't see this issue discussed recently. Have the BGP filtering policies for "most" ISP/NSP's been relaxed to the level of "accept /24's from class A (ARIN-allocated) space"? Am I mis-reading Verio's posted policy? Is there anyone from UUNet who might choose to comment? Is there something else I'm misunderstanding? __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

2 2

[Q] BGP filtering policies
by Henry Yen 09 Apr '02

09 Apr '02

We were recently assigned a /22 from UUNet in conjunction with some transit we're buying from them. The space is inside their superblock, 65.242.0.0/14. We are concerned that our route announcement of this block would be filtered out by some other providers, as it's not class C/swamp space (or even class B space for that matter). Verio's current policy, for one, indicates that this would be so. This is of particular concern to us as our little network encompasses several physical partially-meshed locations, with a mix of varying bandwidths both upstream as well as intra-location. Traffic Engineering is what we think is a reasonable (business) approach to address our flexibility needs, and so we're trying to move to address space(s) that would be least likely to be BGP filtered. We've asked for a different block from UUNet but the request didn't meet with success; UUNet suggested that any problems encountered as a result of this allocation could probably solved by e-mailing any NSP whose traffic interchange with us might be negatively affected (unlikely, to be sure, but still...), and would then change their filter (I'm unconvinced of this scenario). I briefly browsed the NANOG archives, and didn't see this issue discussed recently. Have the BGP filtering policies for "most" ISP/NSP's been relaxed to the level of "accept /24's from class A (ARIN-allocated) space"? Am I mis-reading Verio's posted policy? Is there anyone from UUNet who might choose to comment? Is there something else I'm misunderstanding? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York

2 1

RE: packet reordering at exchange points
by Kavi, Prabhu 09 Apr '02

09 Apr '02

An interesting historical observation, Many years ago when I used to create discrete event simulation network models for a living, I had one project which was to model (what was then) a widely implemented PC TCP stack. I remember that one wart of this implementation was that when packet reordering occurred it collapsed the window size to 1! Anyone know if strange warts like this still exist in desktop systems? Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi(a)tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tuesday, April 09, 2002 12:36 PM > To: Stephen Sprunk > Cc: nanog(a)merit.edu > Subject: Re: packet reordering at exchange points > > > > On Mon, 8 Apr 2002, Stephen Sprunk wrote: > > > Thus spake "Iljitsch van Beijnum" <iljitsch(a)muada.com> > > > But how is packet reordering on two parallell gigabit interfaces > > > ever going to translate into reordered packets for individual > > > streams? > > > Think of a large FTP between two well-connected machines. > Such flows tend > > to generate periodic clumps of packets; split one of these > clumps across two > > pipes and the clump will arrive out of order at the other end. The > > resulting mess will create a clump of retransmissions, then > another bigger > > clump of new data, ... > > I don't think it will be this bad, even if hosts are > connected at GigE and > the trunk is 2 x GigE. In this case, a (delayed) ACK will usually > acknowledge 2 segments so it will trigger transmission of two new > segments. These will arrive back to back at the router/switch > doing the > load balancing. Since there is obviously need for more than 1 > Gbit worth > of bandwidth, it is likely the average queue size is at least > close to 1 > (= ~65% line use) or even higher. If this is the case, there > is a _chance_ > the second packet gains a full packet time over the first and arrives > first at the destination. However, this is NOT especially > likely if both > packets are the same size: the _average_ queue sizes will be > the same so > in half the cases the first packet gains an even bigger > advance over the > second, and only in a fraction of half the cases the second > packet gains > enough over the first to pass it. And then, the destination host still > only sees a single packet coming in out of order, which isn't > enough to > trigger fast retransmit. > > You need to load balance over more than two connections to trigger > unnecessary fast retransmit (over two lines, packet #3 isn't > going to pass > by packet #1), AND you need to send more than two packets > back to back. > Also, you need to be at the same speed as the load balanced lines, > otherwise your packet train gets split up by traffic from > other interfaces > or idle time on the line. > > And _then_, if all of this happens, all the retransmitted > data is left of > window. I'm not even sure if those packets generate an ACK, > and if they > do, if the sender takes any action on this ACK. If this > triggers another > round of fast retransmit, the FR implementation should be considered > broken, IMO. > > > > Packets for streams that are subject to header compression or > > > for voice over IP or even Mbone are nearly always transmitted > > > at relatively large intervals, so they can't travel down parallell > > > paths simultaneously. > > > RTP reordering isn't a problem in my experience, probably > since RTP has an > > inherent resequencing mechanism. > > My point is real time protocols will not see reordering > unless they are > using up nearly the full line speed or there is congestion, > because these > protocols don't send out packets back to back like TCP > sometimes does. How > big are VoIP packets? Even with an 80 byte payload you get > 100 packets per > second = 10 ms between packets, which is more than 80 packet times for > GigE = congestion. And if there is congestion, all > performance bets are > off. > > It seems to me spending (CPU) time and money to do more complex load > balancing than per packet round robing in order to avoid > reordering only > helps some people with GigE connected hosts some of the time. > Using this > time or money to overcome congestion is probably a better investment. > > PS. For everyone looking at their netstat -p tcp output: > packet loss also > counts towards the out of order packets, it is hard to > get the real > out of order figures. > > PS2. Isn't it annoying to have to think about layer 4 to > build layer 2 stuff? > >

1 0

RE: Qwest Transit
by LeBlanc, Jason 09 Apr '02

09 Apr '02

Being a coworker of Dre's, I can attest that his crack pipe is one of the finest. =P We love dre. ;) -----Original Message----- From: Gironda, Andre [mailto:agironda@ebay.com] Sent: Monday, April 08, 2002 9:35 PM To: 'Richard A Steenbergen '; Gironda, Andre Cc: ''Daniel Golding' '; ''Alex Rubenstein' '; ''Andy Dills' '; 'nanog(a)merit.edu ' Subject: RE: Qwest Transit I meant any sales guy selling transit would "like to" ask for strict traffic ratios, while in reality, they don't actually do this. Your email is right on otherwise. I do believe that many transit offerings in the past and currently require some kind of strict traffic ratio to *some* companies. If you still don't think so, drop me an email offline and we can chat more about it. -dre > Thats a mighty fine crack pipe you're smoking from. > > The majority of 95th percentile providers that I am aware of will > charge you only for whatever is higher, inbound OR outbound (the notable > exception to this being Exodus, who added in+out and THEN took 95th > percentile, to extract every last penny from your pocket). > > Infact depending on the provider you choose, you might even be able > to strike some better deals based on your ratios. For example, rumor > has it that Google struck a great deal with AboveNet because all their > inbound traffic (from spidering) helped balance out AboveNet's > peering links (I don't know if that story is accurate or not, but > it has a ring of truth to it). > > To my knowledge Cogent is the only provider who asks for traffic > ratios on their transit connections. The reason? Probably because > Cogent is already taking a massive massive loss on anything they > must transit. Their only chance to make money at the end of the day > is to get as much peering as quickly as possible (hence their buying > spree of "hosed" companys who just happened to have lots of legacy > peering), and since they are answerable to their peers for their > ratios they must pass on those requirements to their customers. > > It's interesting to note how much inbound traffic is "in demand" > by hosting providers. With the breakup of @Home into many regional > cable companies, most of whom havn't the slightest bit of clue how > to build a network let alone a backbone, the traffic profiles change > greatly. My prediction is that a lot of traffic which used to be > peered into @Home at "major exchange points" will turn into transit > connections from other providers. Unfortunately for the cable > companies, the people who they could get the best deals from (the > "mostly hosters") tend to be highly based around the "major exchange > points" cities (to most efficiently pump traffic into the rest of > the internet), not the "rest of the world". > > -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras > PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 > 36 FE B6)

1 0