- Test - lists.nanog.org

Re: Two Tiered Internet
by John Dupuy 14 Dec '05

14 Dec '05

At 08:41 AM 12/14/2005, Michael.Dillon(a)btradianz.com wrote: >QoS is for customers, not for network operators! > >--Michael Dillon That is probably the best way I have heard it put before! Since network bandwidth is a zero-sum game, QoS is simply a method of handling degraded or congested service in a graceful manner. John

1 0

RE: Gothcas of changing the IP Address of an Authoritative DNS Server
by Hannigan, Martin 14 Dec '05

14 Dec '05

> On 14-Dec-05, at 10:02 AM, Joe Abley wrote: > > > > You also want to check all the registries which are superordinate > > to zones your server is authoritative for, and check that any IP > > addresses stored in those registries for your nameserver are > > updated, otherwise you will experience either immediate or future > > glue madness. > > > > A conservative approach to this kind of transition is to arrange > > for your nameserver (or different nameservers hosting the same > > data) to respond on both the old and new addresses, and to > continue > > in that mode until you see no queries directed at the old address > > for some safe-seeming interval (bearing in mind TTLs and cached > > records, alluded to by Steven and Sam). > > If you have access customers (Dial/Broadband/etc) make sure > they know > the IP for your DNS server is changing incase they hardcode IP of > your DNS server into their PCs. It might be wise to keep the old addrs as host routes on interface aliases on the same machine for simplicity sake. (Joe said that kinda). Both unix and cisco support this. You will likely not miss a beat if you're able to do this and see who's using the old addrs(hard coded) after the TTL expires - methinks. If you really care, you could chase down your hard coded users or just shut down and force them to call. The number would dictate which one I suppose. -M<

1 0

RE: Two Tiered Internet
by Hannigan, Martin 14 Dec '05

14 Dec '05

> > On Wed, Dec 14, 2005 at 04:59:44AM -0500, Hannigan, Martin wrote: > > > > Since the model is based around cash, there is no perception > > except you pay, you get priority. > > > > Someone has to pay for the Internet. The users aren't. > > hum... then what am i getting for my monthly 4000+ > bills from telcos and ISPs for "data services" and > "internet transit" services? You don't get priority. :-) -M<

2 1

RE: Two Tiered Internet
by Schliesser, Benson 14 Dec '05

14 Dec '05

Hi. I agree with your comments re customers. (residential customers, in particular) At risk of being flamed, what I'd propose is that regulators should put effort into understanding whether the basic service is broken. If it's not broken then perhaps it is reasonable to allow provider-prioritized traffic. (i.e., if the provider offers a good SLA for basic traffic and lives up to it even in the presence of prioritized traffic) On the other hand, if the provider doesn't guarantee a quality basic service then their request to "prioritize" is in bad-faith; they will effectively be de-prioritizing the basic service. Cheers, -Benson -----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Wednesday, 14 December, 2005 09:36 To: Schliesser, Benson Cc: Per Heldal; NANOG Subject: Re: Two Tiered Internet Hello; My experience is that customers won't put a lot of effort into understanding nuances of what they are being offered, that they will always complain to the people they are paying money to, and that if you think that a good use of your bandwidth with your customers (a business's most precious commodity) is to explain to them why it's a good thing that your service is broken, you're crazy. On Dec 14, 2005, at 10:18 AM, Schliesser, Benson wrote: > > Marshall Eubanks wrote: > >> If these don't work, people will complain. Just imagine for a second >> that cable providers started a service that meant that every channel >> not owned by, say, Disney, had a bad picture and sound. Would this >> be good for the cable companies ? Would their customers be happy ? > > So, the basic issue isn't relative priority. It's the absolute quality > of the common-denominator/lower-priority service (i.e., the baseline). > > If the provider enforces a solid SLA for non-enhanced Internet, > then who > would be upset if they also provide an enhanced option? Of course, I > don't currently have an SLA for my personal cable-modem or DSL > services... > A friend of mine who is also on Cox (and on this list) called up and complained enough to get an SLA from them. I wish I had one. I test a lot of streaming here at home, and I notice when Cox has one of their very frequent 15 second outages. Or their also frequent 5 minute periods of 80-90% packet loss. When Verizon puts their FTTH out here to Clifton, I think I'll get that too and try and multi-home (through tunnels, as I'm certainly not paying either for BGP). Hmm, maybe there's a product there... Regards Marshall > Cheers, > -Benson

1 0

RE: Two Tiered Internet
by Schliesser, Benson 14 Dec '05

14 Dec '05

Marshall Eubanks wrote: > If these don't work, people will complain. Just imagine for a second > that cable providers started a service that meant that every channel > not owned by, say, Disney, had a bad picture and sound. Would this > be good for the cable companies ? Would their customers be happy ? So, the basic issue isn't relative priority. It's the absolute quality of the common-denominator/lower-priority service (i.e., the baseline). If the provider enforces a solid SLA for non-enhanced Internet, then who would be upset if they also provide an enhanced option? Of course, I don't currently have an SLA for my personal cable-modem or DSL services... Cheers, -Benson

2 1

RE: Two Tiered Internet
by Hannigan, Martin 14 Dec '05

14 Dec '05

> --- Joe McGuckin <joe(a)via.net> wrote: > > > What good is 6Mbit DSL from my ISP (say, SBC for > > example) if only a small > > portion of the net (sites that pay for non-degraded > > access) loads at a > > reasonable speed and everything else sucks? > > There are two possible ways of having a tiered system > - one is to degrade competitors/those who don't pay, > and the other is to offer a premium service to those > who do pay. > > Would your perception of those two scenarios be > identical? Since the model is based around cash, there is no perception except you pay, you get priority. Someone has to pay for the Internet. The users aren't. -M<

3 2

RE: Let's talk about ICANN
by Hannigan, Martin 14 Dec '05

14 Dec '05

> > (b) Would that prevent discussion here? ;-) This is a trick question, right?

1 0

www.google.com latency/packet loss/very slow thru savvis
by Erik Sundberg 13 Dec '05

13 Dec '05

hey is any one seeing a slow google to day... packet loss 22 hops... visual traceroute show that it goes from chicago to los angeles to singapore to italy to amsterdam and then finally to google in sunnyvale ca. router@m40> ping google.com PING google.com (72.14.207.99): 56 data bytes 64 bytes from 72.14.207.99: icmp_seq=1 ttl=243 time=447.727 ms 64 bytes from 72.14.207.99: icmp_seq=2 ttl=244 time=445.543 ms 64 bytes from 72.14.207.99: icmp_seq=3 ttl=243 time=442.937 ms 64 bytes from 72.14.207.99: icmp_seq=4 ttl=244 time=443.776 ms 64 bytes from 72.14.207.99: icmp_seq=5 ttl=243 time=446.607 ms 64 bytes from 72.14.207.99: icmp_seq=6 ttl=243 time=451.655 ms 64 bytes from 72.14.207.99: icmp_seq=7 ttl=243 time=451.842 ms 64 bytes from 72.14.207.99: icmp_seq=8 ttl=244 time=447.052 ms 64 bytes from 72.14.207.99: icmp_seq=9 ttl=243 time=448.432 ms 64 bytes from 72.14.207.99: icmp_seq=10 ttl=244 time=433.543 ms 64 bytes from 72.14.207.99: icmp_seq=12 ttl=244 time=455.547 ms 64 bytes from 72.14.207.99: icmp_seq=13 ttl=243 time=451.316 ms 64 bytes from 72.14.207.99: icmp_seq=14 ttl=243 time=444.915 ms 64 bytes from 72.14.207.99: icmp_seq=16 ttl=243 time=444.318 ms ^C --- google.com ping statistics --- 17 packets transmitted, 14 packets received, 17% packet loss round-trip min/avg/max/stddev = 433.543/446.801/455.547/5.075 ms router@m40> traceroute google.com traceroute to google.com (72.14.207.99), 30 hops max, 40 byte packets 1 s216240-1.rtr1s.216240.uschcg2-j20c.savvis.net (64.240.49.173) 5.275 ms 4.889 ms 4.378 ms 2 dcr2-so-2-2-0.Chicago.savvis.net (208.172.3.81) 5.191 ms 60.075 ms 4.844 ms 3 bcs2-so-0-0-0.Dallas.savvis.net (204.70.192.98) 30.408 ms 30.099 ms 30.683 ms MPLS Label=595600 CoS=0 TTL=1 S=1 4 bcs1-so-6-0-0.Dallas.savvis.net (204.70.192.49) 30.093 ms 30.035 ms 30.314 ms MPLS Label=294001 CoS=0 TTL=1 S=1 5 dcr2-so-2-0-0.LosAngeles.savvis.net (204.70.192.86) 62.299 ms 62.363 ms 62.326 ms MPLS Label=442832 CoS=0 TTL=1 S=1 6 dcr1-as0-0.LosAngeles.savvis.net (204.70.192.117) 158.574 ms 62.171 ms 62.628 ms 7 bpr3-so-0-0-0.LosAngelesEquinix.savvis.net (208.172.44.106) 62.246 ms 62.182 ms 64.274 ms 8 singapore-telecommunications-ltd.LosAngelesEquinix.savvis.net (208.174.196.6) 64.209 ms 62.281 ms 62.374 ms 9 laxeq-cr1.ge-3-0-0.ix.singtel.com (203.208.182.45) 62.767 ms ge-0-3-0.laxeq-cr1.ix.singtel.com (203.208.168.221) 62.958 ms 62.604 ms MPLS Label=126512 CoS=0 TTL=1 S=1 10 so-3-3-2.sngc3-cr1.ix.singtel.com (203.208.154.25) 227.841 ms 225.874 ms 226.254 ms MPLS Label=100288 CoS=0 TTL=1 S=1 11 ge-1-0-0.sngc3-ar2.ix.singtel.com (203.208.172.158) 232.373 ms ge-0-0-0.sngc3-ar2.ix.singtel.com (203.208.172.166) 232.503 ms 239.240 ms 12 203.208.147.238 (203.208.147.238) 424.056 ms * 429.784 ms 13 pal6-pakistan-telecom-1-pk.pal.seabone.net (195.22.197.193) 477.452 ms 478.886 ms * 14 amsix-ams2-racc1.ams.seabone.net (195.22.213.221) 483.282 ms 491.266 ms 480.559 ms 15 core1.ams.net.google.com (195.69.144.247) 448.393 ms 442.054 ms 435.464 ms 16 216.239.43.90 (216.239.43.90) 452.569 ms 460.223 ms 451.533 ms MPLS Label=588419 CoS=0 TTL=1 S=1 17 72.14.236.216 (72.14.236.216) 429.854 ms 433.688 ms 448.938 ms MPLS Label=775643 CoS=0 TTL=1 S=1 18 66.249.94.98 (66.249.94.98) 448.831 ms 439.760 ms 453.181 ms 19 66.249.94.69 (66.249.94.69) 444.019 ms * 439.384 ms 20 72.14.236.183 (72.14.236.183) 446.575 ms 438.125 ms * 21 * 72.14.236.134 (72.14.236.134) 451.592 ms 457.254 ms 22 72.14.207.99 (72.14.207.99) 452.669 ms * 441.830 ms Thanks Erik

7 7

RE: Let's talk about ICANN
by Hannigan, Martin 13 Dec '05

13 Dec '05

> I'm surprised that I've yet to see any mention here on NANOG about the > Internet Governance Forum discussions that were held at the WSIS / > United Nations summit in Tunisia a few weeks ago. From my reading of > the various articles, it appears that the EU together with some > developing nations wanted to wrest "control of the Internet" away from > the US and ICANN. Was everyone unaware of this, or were you just > counting on Vint Cerf to talk sense into the delegates from the other > countries? > > <http://news.com.com/U.N.+says+its+plans+are+misunderstood/200 > 8-1028_3-5959117.html> > > Then there was ICANN's sudden delay of discussion/approval of .xxx: > > <http://news.google.com/news?q=icann+xxx> > > followed by their approval of .asia: > > http://news.google.com/news?q=icann+asia > > Is anyone here paying any attention to any of this? > > jc I'm on the 2006-2009 NRO Address Supporting Organization Advisory Council (www.nro.com) (www.aso.icann.org) and was at the Vancouver meeting. There were quite a few people from the NANOG community at the ICANN meeting in Vancouver. I would think that ICANN is off topic for NANOG? -M<

6 5

REMINDER: NANOG36 submissions due!
by Steve Feldman 13 Dec '05

13 Dec '05

Just a reminder that proposals to present at NANOG 36 are due this Thursday, December 15. Send your omplete proposals, including abstract and slides, to nanog-support(a)merit.edu. The full call for presentations is available at http://www.nanog.org/mtg-0602/cfp36.html Steve Feldman Program Committee chair (Sorry for the duplicate, I forgot the subject the first time.)

1 0