- NANOG - lists.nanog.org

Re: shim6 @ NANOG (forwarded note from John Payne)
by Brandon Butterworth 01 Mar '06

01 Mar '06

> There is > talk at present of whether the protocol needs to be able to > accommodate a site-policy middlebox function to enforce site policy Certainly, firewalls may be the only point such policy will work when the hosts are hidden behind them on a corporate lan 10 years of host legacy later I don't see managing this being fun. easier to upgrade a few routers that have to stay current anyway > The scope of > that policy mediation function depends strongly on people like you > saying "at a high level, this is the kind of decision I am not happy > with the hosts making". For our web hosting farms I'd rather our hosts host and not route, there's too many of them and they are busy enough we don't want to have to buy more to do the job a C or J box of asics should do better, not accounting for the admin of managing it over 1000s of hosts instead of a few routers. Routing is also the responsiblity of a different team from hosting brandon

1 0

FYI - China To Launch Alternate Country Code Domains
by william(at)elan.net 01 Mar '06

01 Mar '06

---- From: Michael Geist <mgeist(a)pobox.com> Date: February 28, 2006 9:24:09 AM EST To: dave(a)farber.net Subject: China To Launch Alternate Country Code Domains Dave, China is preparing to launch what appears to be an alternate root. Starting tomorrow, they will establish four country-code domains. In addition to the current dot-cn, they will offer Chinese character versions of dot-China, dot-net, and dot-com. As one article puts it, this "means Internet users don't have to surf the Web via the servers under the management of the Internet Corporation for Assigned Names and Numbers (ICANN) of the United States." Coverage from China is at http://english.people.com.cn/200602/28/eng20060228_246712.html I've got some quick commentary at <http://michaelgeist.ca/component/option,com_content/task,view/id,1130/Itemi d,85/nsub,/> which includes: "The alternate root has always lurked in the background as a possibility that would force everyone to rethink their positions since it would enable a single country (or group of countries) to effectively pack up their bags and start a new game. The U.S. control would accordingly prove illusory since a new domain name system situated elsewhere would be subject to its own rules. While the two could theoretically co-exist by having ISPs simply recognize both roots, the system could "break" if both roots contained identical extensions. In other words, one root can have dot-com and other other can have dot-corp, but they can't both have dot-com. It is with that background in mind that people need to think about a press release issued yesterday in China announcing a revamping of its Internet domain name system. Starting tomorrow, China's Ministry of Information Industry plans to begin offering four country-code domains. In addition to the dot-cn country code domain, three new Chinese character domains are on the way: dot-China, dot-net, and dot-com. As the People's Daily Online notes this "means Internet users don't have to surf the Web via the servers under the management of the Internet Corporation for Assigned Names and Numbers (ICANN) of the United States." In other words, the Chinese Internet becomes a reality tomorrow. With it, the rules of the game may change as 110 million Internet users will suddenly have access to a competing dot-com (albeit in a different character set) and will no longer rely exclusively on ICANN for the resolution of Internet domain name queries. This change was probably inevitable regardless of the status of ICANN, however, the U.S. position can't possibly have helped matters. Indeed, some might note that while Congress has been criticizing U.S. companies for cooperating with Chinese law enforcement and thereby harming Internet freedoms, those same Congressional leaders may have done the same by refusing to even consider surrendering some control over the Internet root to the international community and thereby opening the door to an alternate root that could prove even worse from a freedom perspective. This week's announcement certainly doesn't mark the end of a global interoperable Internet. It does move one step further toward that path since in Internet governance terms, the credible threat is now real." MG --********************************************************************** Professor Michael A. Geist Canada Research Chair in Internet and E-commerce Law University of Ottawa, Faculty of Law 57 Louis Pasteur St., Ottawa, Ontario, K1N 6N5 Tel: 613-562-5800, x3319 Fax: 613-562-5124 mgeist(a)pobox.com http://www.michaelgeist.ca

7 6

NZNOG 06 - March 22-24 , Registrations online
by Simon Lyall 01 Mar '06

01 Mar '06

NZNOG 06 - Registrations now online. http://www.nznog.org The next conference of the New Zealand Network Operators' Group is to be held in Wellington, New Zealand between 22-24 March 2006. The conference is on the week before the ICANN meeting in Wellington so people can attend both events. NZNOG meetings provide opportunities for the exchange of technical information and discussion of issues relating to the operation and support of networked services, with particular emphasis on New Zealand. The conference has a strong technical focus with the aim of attracting a strong turnout of technical personnel. The conference fee is affordable to most to encourage greater participation This year we have a strong programme of New Zealand and overseas speakers on a wide range of topics over 3 days. The programme includes talks on VoIP, DNSSEC, IPv6, BGP, 10G Networks, Peering, QoS and Content-delivery. NZNOG 2006 registration fee is $250 for three days See http://www.nznog.org for more details. My apologies if you see multiple copies of this announcement. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

Identify amount of traffic to special IP address in Radius
by Joe Shen 01 Mar '06

01 Mar '06

Hi, In order to summrize broadband subsciber's traffic data, we need to identify those traffic to our video servers by BRAS which use Radius. Currently, our BRAS could only report total amount of traffic a subscriber transferred. Could we make BRAS genenrate radius accounting data including tags indicating destination IP information ? thanks Joe __________________________________ Do you Yahoo!? Yahoo! Movies - Search movie info and celeb profiles and photos. http://sg.movies.yahoo.com/

2 3

Re: Transit LAN vs. Individual LANs
by Scott Weeks 01 Mar '06

01 Mar '06

----- Original Message Follows ----- From: "Stephen Sprunk" <stephen(a)sprunk.org> > Thus spake "Scott Weeks" <surfer(a)mauigateway.com> > > From: "Stephen Sprunk" <stephen(a)sprunk.org> > >> ITYM two big transit LANs -- one must be prepared for a > >> switch to fail. > > > > These're going to be router-to-router connections (each > > AR is connected to both CRs) and I had thought about > > tying them all into one VLAN vs. PTP Gig-E. I was just > > trying to find out the operational benefits of either > design. > > If your physical topology is going to be PTP links, then > you should go with PTP at the logical level as well. > Making one topology look like another is generally a bad > idea. This is what I decided to do. Thanks everyone, your ideas (and those of a good friend) helped me to find the KISS solution. :-) scott

1 0

Cogent peering issues between San Jose and San Francisco
by Peter Kranz 01 Mar '06

01 Mar '06

Anyone else experiencing this? Paths through Cogent to San Jose are getting 100 ms of latency at p10-0.core01.sjc03.. Its been a daily occurrence for about a week now. Latency is normal during the day until about 3-4pm when it starts to rise to 100 ms and stays there until a little after midnight. traceroute to www.apple.com.akadns.net (17.254.0.91), 30 hops max, 38 byte packets 1 10.Ge1-0-10-Cr01-365m-SFO.unwiredltd.net (204.11.104.4) 0.454 ms 0.487 ms 0.424 ms 2 g0-8.na21.b007352-0.sfo01.atlas.cogentco.com (38.99.206.145) 0.452 ms 0.406 ms 0.393 ms 3 t3-4.mpd01.sfo01.atlas.cogentco.com (154.54.3.129) 0.645 ms 0.505 ms 0.479 ms 4 g3-0-0.core02.sfo01.atlas.cogentco.com (154.54.3.117) 0.480 ms 0.418 ms 0.386 ms *** 5 p10-0.core01.sjc03.atlas.cogentco.com (66.28.4.133) 95.705 ms 89.578 ms 88.039 ms *** 6 verio.sjc03.atlas.cogentco.com (154.54.11.246) 86.466 ms 84.790 ms 85.694 ms 7 xe-0-2-0.r20.snjsca04.us.bb.verio.net (129.250.2.72) 87.477 ms 91.883 ms 112.126 ms MPLS Label=100096 CoS=0 TTL=1 S=1 8 xe-1-1.r02.snjsca04.us.bb.verio.net (129.250.2.29) 254.899 ms 273.583 ms 204.051 ms 9 ge-3.internap.snjsca04.us.bb.verio.net (129.250.12.14) 89.372 ms 85.061 ms 87.248 ms 10 border1.ge0-0-bbnet2.sje.pnap.net (66.151.144.68) 88.441 ms 91.033 ms 93.412 ms traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets 1 10.Ge1-0-10-Cr01-365m-SFO.unwiredltd.net (204.11.104.4) 0.468 ms 0.414 ms 0.324 ms 2 g0-8.na21.b007352-0.sfo01.atlas.cogentco.com (38.99.206.145) 0.500 ms 0.553 ms 0.460 ms 3 t3-4.mpd01.sfo01.atlas.cogentco.com (154.54.3.129) 0.640 ms 0.567 ms 0.527 ms 4 g3-0-0.core02.sfo01.atlas.cogentco.com (154.54.3.117) 0.506 ms 0.470 ms 0.449 ms *** 5 p10-0.core01.sjc03.atlas.cogentco.com (66.28.4.133) 93.822 ms 94.459 ms 95.483 ms *** 6 ex1-p1-1.eqsjca.sbcglobal.net (151.164.248.249) 96.902 ms 99.557 ms 101.810 ms 7 bb1-p6-0.crscca.sbcglobal.net (151.164.242.229) 103.717 ms 103.422 ms 100.601 ms 8 bb2-p5-0.pltnca.sbcglobal.net (151.164.43.170) 114.931 ms 92.110 ms 93.101 ms 9 ded1-8-3-0.pltn13.pbi.net (151.164.191.245) 220.898 ms traceroute to www.mci.com (198.4.5.227), 30 hops max, 38 byte packets 1 10.Ge1-0-10-Cr01-365m-SFO.unwiredltd.net (204.11.104.4) 0.923 ms 0.414 ms 0.425 ms 2 g0-8.na21.b007352-0.sfo01.atlas.cogentco.com (38.99.206.145) 0.456 ms 0.431 ms 0.474 ms 3 t3-4.mpd01.sfo01.atlas.cogentco.com (154.54.3.129) 0.594 ms 0.551 ms 0.474 ms 4 g3-0-0.core02.sfo01.atlas.cogentco.com (154.54.3.117) 0.458 ms 0.443 ms 0.377 ms *** 5 p10-0.core01.sjc03.atlas.cogentco.com (66.28.4.133) 95.815 ms 92.236 ms 89.806 ms *** 6 POS4-3.BR5.SAC1.ALTER.NET (204.255.174.209) 91.906 ms 91.998 ms 92.930 ms 7 0.so-2-1-0.XL1.SAC1.ALTER.NET (152.63.52.226) 94.003 ms 96.119 ms 98.381 ms 8 0.so-7-0-0.CL1.IAD5.ALTER.NET (152.63.34.142) 161.592 ms 165.041 ms 165.997 ms 9 500.ATM4-0.GW2.IAD5.ALTER.NET (152.63.34.173) 165.745 ms 163.512 ms Peter Kranz Founder/CEO - Unwired Ltd www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz(a)unwiredltd.com

1 0

SUMMARY - 95th percentile calculation
by Jo Rhett 28 Feb '06

28 Feb '06

My thesis that I wanted to prove or disprove was that the market seems to have standardized how they calculate 95th percentile. Years ago if you asked all your uplinks you'd get wildly different answers. Averages or max values over days, weeks or months. Rarely would two answers jive. But it appeared that most providers are now using 5 minute averages as the value input over a billing month for 95th% calculation. Was this truly standard now? The answer is yes. All of our paid transit links use 5 minute averages, and all but one of the replies to my query here did too. 8 providers use 5 minute averages of 30 second counter checks as the base value calculated over the billing month. 2 providers use 5 minute averages of 1 minute counter checks as the base value calculated over the billing month. 8 providers use 5 minute implicit averages (a single counter check) as the base value calculated over the billing month.* 1 provider uses the maximum value found in 5 minutes of 1 minute counter checks for the 5 minute value, and calculates that over the billing month. 1 provider uses 5 minute implicit averages (a single counter check) but calculates that over a fixed 30 day month. (I didn't ask what they did with the extra days) At first glance my tendancy would be to say that 20 answers is hardly authoritative, but the 30 second counters (first listed) comprise 6 of the top US bit movers, and 2 of the largest bit pushers so I'm satisfied with the results for my purposes. * One very large bit mover that I know uses 32 bit counters claimed to only be checking every 5 minutes. We're pushing enough to them to rotate that counter in that interval, so I actually disbelieve this answer but I'm reporting it as they said it. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation

3 2

Re: AOL Megaproxies?
by Nathan March 28 Feb '06

28 Feb '06

Did that and it seemed like they weren't proxying unknown traffic but one test isn't really a good indication of how their entire system works. Hoping to get a response from someone who actually knows their network. :) - Nathan Bill Nash wrote: > > Nothing digging an AOL cd out of the trash wouldn't fix. =) I have a > friend that works there, but he's unresponsive at the moment. > > - billn > > On Mon, 27 Feb 2006, Nathan March wrote: > >> Is anyone on this list familiar with the AOL "megaproxies"? >> >> I'm trying to find out if they only proxy HTTP/HTTPS traffic or if >> it's all TCP connections. I'm working on setting up load balancers >> for a client application and need to know if I can expect users to >> keep coming from the same IP for the most part. >> >> Normally I'd think that they only proxy web connections, but some >> links say otherwise: >> >> http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_qanda_item09… >> - Refers to TCP connections as a general topic, not just http/s. >> >> http://technet2.microsoft.com/WindowsServer/en/Library/bf3a1c95-f960-4ed3-b… >> >> - Refers to the AOL proxies with "all TCP connections" >> >> Anyone have any experience with AOL in this regard? >> >> Thanks, >> Nathan >> >

1 0

AOL Megaproxies?
by Nathan March 27 Feb '06

27 Feb '06

Is anyone on this list familiar with the AOL "megaproxies"? I'm trying to find out if they only proxy HTTP/HTTPS traffic or if it's all TCP connections. I'm working on setting up load balancers for a client application and need to know if I can expect users to keep coming from the same IP for the most part. Normally I'd think that they only proxy web connections, but some links say otherwise: http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_qanda_item09… - Refers to TCP connections as a general topic, not just http/s. http://technet2.microsoft.com/WindowsServer/en/Library/bf3a1c95-f960-4ed3-b… - Refers to the AOL proxies with "all TCP connections" Anyone have any experience with AOL in this regard? Thanks, Nathan

1 0

95th percentile - the sociology study.
by Jo Rhett 27 Feb '06

27 Feb '06

I didn't realize when I asked for how people handled a mathematical function for billing purposes, that the results would be more interesting to a socialogist than a network provider. I figured How do you (not how do I)... would be pretty specific, but apparently I underestimated the interesting ways that would be misread. 7 people wrote me with exactly the answers to the questions I asked. Nice. 7 people wrote to tell me how to calculate 95th percentile, but didn't include answers to any of the questions I asked. * On reply/request 5 of them did eventually answer the questions 4 people wrote to tell me how to calculate 95th percentile, but did remember to answer the questions I asked. 2 people wrote to tell me I was doing it wrong, and that I didn't understand what 95th percentile was. * Both of them eventually admitted that they don't work in a place which calculates 95th percentile for their customers. The remainder of my 20 samples were offlist queries/conversations with other providers. Some rough statistics from an admittedly small sample: 1/3 of the nanog repliers understood the question and knew how to answer it. Hmmm. Nanog clue level is definitely improving. All but three of the people who tried to teach me how to calculate 95th percentile were polite and clueful when I reminded them that I wanted the math, not a tutorial. A couple of misunderstanding actually wandered off into statistical analysis ramblings which was an amusing offset to the next set. Only three of the people insisted on telling me I was doing it wrong (never posted how we were doing it in the first place, so this was amusing) and tried to clue by four me into their approach. 2 did the math wrong in their long rants sent back to me ;-) 1 tried to convince me that modern equipment can't handle being sampled more often than every 5 minutes. And all three that tried to argue with me showed in their analysis that they don't deal with anything approaching 100Mb peering, nevermind 1g or 10g. And for those of you who can count, yes, one of the people who tried to teach me how to calculate 95th percentile didn't respond back either positively or negatively when I tried to remind him of the questions asked, and one was rude. (I don't blame him, after the 10th or so reply I was too) For statistical analysis: 2 women responded. Unfortunately one of them disagreed with a male counterpart from the same company and when I asked them to clarify it turns out the guy was right. (the girl's math was excellent, but based on an incorrect assumption. stereotype reversal in action) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation

2 2