- NANOG - lists.nanog.org

Re: US transit providers with slightly better than average International connectivity?
by Sargun Dhillon 13 Aug '07

13 Aug '07

Drew Weaver wrote: > How about to this IP? > > 62.150.200.10 > > > > -----Original Message----- > From: Sargun Dhillon [mailto:sdhillon@decarta.com] > Sent: Monday, August 13, 2007 1:58 PM > To: Drew Weaver > Cc: 'nanog(a)merit.edu' > Subject: Re: US transit providers with slightly better than average International connectivity? > > Drew Weaver wrote: > >> Howdy, I know with the trans-atlantic and trans-pacific connectivity >> being what it is these days that getting reliable (i.e. low latency < >> 200, low packet loss < 5% total round-trip) to countries such as AE >> and others is kind of a "shot in the dark". However, I wanted to ping >> the list and see if anyone has had 'better luck/worse luck' with >> particular transit providers. We're currently utilizing Time Warner >> Telecom, Level3, and Global Crossing as our transit partners and we're >> shopping for a fourth at this time, we would really like to find a >> transit provider with 'better' international presence. >> >> Any suggestions based on experience? >> >> Thanks, >> >> -Drew >> >> > As a test point let's try: 212.58.224.131 > That's the BBC. Posting traceroutes would be the best. Here is mine from > internap: > core1.t6-1-bbnet1.sje.pnap.net 0.0% 2895 2.1 21.3 1.9 1671. 101.6 > xe-1-3.r02.snjsca04.us.bb.gin.ntt.net 1.7% 2895 2.1 25.7 2.0 1301. 92.6 > xe-1-2.r03.snjsca04.us.bb.gin.ntt.net 0.8% 2895 2.2 25.5 2.0 1764. 108.7 > sjo-bb1-link.telia.net 0.0% 2895 2.3 15.3 2.1 1680. 109.5 > nyk-bb1-link.telia.net 0.2% 2895 73.8 86.1 73.7 1596. 101.4 > ldn-bb1-pos7-1-0.telia.net 0.0% 2895 143.1 155.5 141.8 1551. 100.4 > ldn-bb1-link.telia.net > ldn-bb1-link.telia.net > 9. ldn-b1-pos3-0.telia.net 0.0% 2895 144.9 163.2 141.8 1470. 99.8 > ldn-b1-link.telia.net > 10. siemens-118436-ldn-b1.c.telia.net 0.0% 2895 144.8 165.2 141.9 1470. > 106.4 > 11. 212.58.238.153 0.1% 2895 143.3 157.7 141.9 1386. 97.5 > 12. rdirwww-vip.thdo.bbc.co.uk 0.1% 2895 146.3 156.0 141.8 1636. 99.4 > > > -- > > Sargun Dhillon > deCarta > sdhillon(a)decarta.com > www.decarta.com > > > ATT: Success rate is 100 percent (5/5), round-trip min/avg/max = 200/203/208 ms Global Crossing: 283 msec SAVVIS: 245.461 msec QWEST: min/avg/max = 312/313/317 UUNET: 379 msec Level3: min/avg/median/max/mdev/stddev = 244/252.8/252/280/2.332/9.432 ms I just used the looking glasses to check latency -- Sargun Dhillon deCarta sdhillon(a)decarta.com www.decarta.com

2 1

Re: [policy] When Tech Meets Policy...
by Paul Ferguson 13 Aug '07

13 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Roland Dobbins <rdobbins(a)cisco.com> wrote: >There's a case to be made that a policy which results in organizations registering and owning domain names which are close to the intended domain anme but represent a common typographical transition is desirable from a security standpoint . . . > I don't think anyone could reasonably question the legitimacy for someone like, say, Google, registering "gogle.com" or "goggle.com". It should raise eyebrows, however, if "goggle.com" was registered to RBusiness Network. Or "allitalia.org", etc. You get the idea. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGwOB3q1pz9mNUZTMRAtaCAKCKJPbiGqAAYeaUHnWL5aFxzKjrhgCgkY4W ruSoXSTqVYbpLarBVmSXgbE= =kB6m -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Anyone from Senderbase, or ironport around?
by Drew Weaver 13 Aug '07

13 Aug '07

Please tag me off-list, also if anyone knows of any way to reach anyone there please let me know. Thanks, -Drew

1 0

Re: [ppml] too many variables
by Joel Jaeggli 13 Aug '07

13 Aug '07

John Paul Morrison wrote: > Can't any network problem can be solved by adding another layer of > indirection? > > Don't all the various nodes in a system simply "disappear" when another > technology comes along to organize, replace and manage the problem > differently? With iBGP there's been confederations and route-reflectors > to divide the problem into smaller pieces, even MPLS to remove a lot of > the scalability issues. > > But perhaps in the future, after many more consolidations and > bankruptcies, there may only be a couple of major carriers left. This > would solve a lot of BGP decision making algorithms. Not if one of them is covad... > You'd either go with the Red ISP or the Blue ISP, just like politics! Leaving most stake holders poorly served just as they are by blue party red party. I don't think hoping for a high level of monopoly consolidation to address the issue of table growth is reasonable. As an enterprise or individual I'm still going to choose both meaning my stub-AS and address space will continue to consume slots in the routing table. > > > > Paul Vixie wrote: >>>> ... is that system level (combinatorial) effects would limit Internet >>>> routing long before moore's law could do so. >>>> >>> It is an easy derivative/proxy for the system level effect is all. Bandwidth >>> for updates (inter and intra system) are another choking point but folks >>> tend to be even less aware of those than cpu. >>> >> >> is bandwidth the only consideration? number of graph nodes and number of >> advertised endpoints and churn rate per endpoint don't enter into the limits? >> at what system size does speed of light begin to enter into the equation? >> >> (note, as i told geoff huston: if it seems like john scudder's outbound BGP >> announcement compression observations are relevant, or that moore's law is >> relevant, then you're misunderstanding my question or i'm asking it wrong.) >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN Public Policy >> Mailing List (PPML(a)arin.net) >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services >> Help Desk at info(a)arin.net if you experience any issues. >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML(a)arin.net) > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info(a)arin.net if you experience any issues.

1 0

Re: [policy] When Tech Meets Policy...
by Brandon Butterworth 13 Aug '07

13 Aug '07

> I picked on example, there have been plenty of examples in the past of > folks just barely able to come up with 7$/yr for domain registration and > using donated hosting for their non-profit thing. It's a shame, they can probably find other benefactors. I doubt there are many cases though so is the benefit to those few worth the cost to the masses? > there is consumer protection today in the purchase system, do we want > to remove that in the future. Or do we want to find another method to > crack down on this problem without hurting consumers? I've not noticed any registrars offering to refund Still, plenty of smart people are controlling this so either it's a terribly hard problem or they feel it's better this way. I'm sure they could come up with a compromise such as registrars only get the refund if they do less than x% per month, the genuine refunds are likely to fit within a small x that makes the tasting not worthwhile. brandon

1 0

Re: [policy] When Tech Meets Policy...
by Chris L. Morrow 13 Aug '07

13 Aug '07

On Mon, 13 Aug 2007, William Herrin wrote: > Chris, > > Suggestion B in ICANN's information request was: > > "making the ICANN annual transaction fee (currently 0.20 USD per year) > apply to names deleted during the [5-day Add Grace Period]," > > Wouldn't this essentially end the bad-behavior domain tasting without > hurting grandma-jones with her typo? This would incur a 20 cent/domain fee for return of the domain inside the grace period, yes? that would add a slow drain to the taster's pocketbooks, is that slow-drain enough to make tasting less profitable? or 'not profitable'? If so, then yes probably it'd slow tasting or end it. I don't think that a 'processing fee' is abnormal on returned items so that might even sit well enough with grandma-jones (in my example). > And if it was still profitable to taste domain names, wouldn't it pump > so much money into ICANN that they could lower the annual fees for the > rest of us? hey lookie, a nice side effect :)

1 0

Re: [policy] When Tech Meets Policy...
by Brandon Butterworth 13 Aug '07

13 Aug '07

> but today that provision is: If you buy a domain you have 5 days to > 'return' it. The reason behind the return could be: "oops, I typo'd" Fine, I don't recall that being the case previously so somone thought to introduce it > "hurray, please refund me for the 1M domains I bought 4.99 days ago!". The > 'protect the consumer' problem is what's enabling tasting. but it's not rocket science to see this simple abuse nor to stop it "one mistake, fine. N mistakes? better take more care, sorry" Sounds like poor management, they can easily redeem the situation by changing the rules again. Why haven't they? This is now sounding like willful negligence brandon

1 0

US transit providers with slightly better than average International connectivity?
by Drew Weaver 13 Aug '07

13 Aug '07

Howdy, I know with the trans-atlantic and trans-pacific connectivity being what it is these days that getting reliable (i.e. low latency < 200, low packet loss < 5% total round-trip) to countries such as AE and others is kind of a "shot in the dark". However, I wanted to ping the list and see if anyone has had 'better luck/worse luck' with particular transit providers. We're currently utilizing Time Warner Telecom, Level3, and Global Crossing as our transit partners and we're shopping for a fourth at this time, we would really like to find a transit provider with 'better' international presence. Any suggestions based on experience? Thanks, -Drew

3 2

Re: [RRG] Routers in DFZ
by Eliot Lear 12 Aug '07

12 Aug '07

John, > Done. draft-ietf-idr-bgp-multisession-03 provides the necessary > protocol machinery. While that draft looks reasonable for its intended purpose, I think Dino was talking about actually shoveling less crap around, router by router. That having been said, I've somewhat lost the plot here. Is the point to allow for priority processing of certain types of information in the face of a performance problem? If so, that's a fine *tactical* and incremental approach (although I don't think much of using a TCP window as application layer flow control - it leads to bad behaviors on both sides when the number of connections increase [See RFC-793, Page 42, "Managing the Window"). But to your original point, that one cannot simply assume a linear death march, I'd agree. I think Tony and others' points were that the issue here is in cost and development curves, looking many MANY years out. If we can find an even better approach to avoid brute force with acceptable trade-offs (and those are a lot of ifs), then we've advanced the state of the art and that's a good thing. Eliot

1 0

RE: [ppml] too many variables
by michael.dillon＠bt.com 12 Aug '07

12 Aug '07

> And yet people still say the sky is falling with > respect to routing convergence and FIB size. > Probably a better comparison BTW, would be with a Actually, the better comparison is with the power of current processors used in Juniper and Cisco gear with the current Moore's law power of common off-the-shelf PC processors. Then go back to the point in time when there were real actual issues with FIB size on routers, and look at the same relative power. Today, is there a bigger or a smaller gap than way back when there were real problems on the net. If the gap is bigger or the same, then we are nuts to worry about it. If the gap is significantly smaller then we should get some serious researchers to figure out the real limits of current technology and the future technology at the point where the gap has gone to zero. --Michael Dillon

1 0