Re: NANOG58 parking
42 a day is perfect.. Now your town car expense will go through with zero problems.. ;) Sent from my T-Mobile 4G LTE Device Original message From: Roy Date: 05/05/2013 12:09 PM (GMT-08:00) To: Cc: NANOG Subject: Re: NANOG58 parking On 5/5/2013 11:12 AM, Jeff Wheeler wrote: > I noticed that some folks were unhappy with the parking fee in Orlando. > > The Roosevelt New Orleans, for NANOG 58, tells me that the only > on-site parking is valet for $42/day. Anyone planning to drive or > stay at a different hotel may want to consider that in advance. > Its the airline pricing scheme. Show cheap prices and then make it up in fees :-)
Re: NANOG58 parking
On 5/5/2013 11:12 AM, Jeff Wheeler wrote: I noticed that some folks were unhappy with the parking fee in Orlando. The Roosevelt New Orleans, for NANOG 58, tells me that the only on-site parking is valet for $42/day. Anyone planning to drive or stay at a different hotel may want to consider that in advance. Its the airline pricing scheme. Show cheap prices and then make it up in fees :-)
NANOG58 parking
I noticed that some folks were unhappy with the parking fee in Orlando. The Roosevelt New Orleans, for NANOG 58, tells me that the only on-site parking is valet for $42/day. Anyone planning to drive or stay at a different hotel may want to consider that in advance. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts
Re: HTTPS-everywhere vs. proxy caching
On Fri, May 3, 2013 at 12:06 PM, Jay Ashworth wrote: > It occurs to me that I don't believe I've seen any discussion of the > Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated > sessions, like non-logged-in users browsing sites like Wikipedia. > > That traffic's not cacheable, is it? Proxy caches on services like > mobile 3/4G, or smaller ISPs, or larger corporations can't cache it, I > wouldn't think, which means both that they will see traffic increases, > and that the end sites will as well. > > Has this been discussed and I missed it? Do I improperly understand > transparent caching? Or is this just a bomb waiting to go off? > > I assume that Wikipedia themselves are on top of the idea that their > in-house reverse-proxies won't be carrying that traffic (though I don't > actually know what their architecture looks like anymore), but.. > If anyone's curious about Wikipedia (we're open with our architecture) - we aren't really effected by using https instead of http for non logged in sessions. I'm assuming all of the other major sites use similar methods. The path goes user <--> LVS load balancer <--> nginx ssl termination <--> varnish (caching layer) <--> (if cache miss) application layer The only extra "hop" for https is the ssl termination, and while if all of a sudden 100% of our traffic switched from http to https, we'd be underprovisioned and have to scramble, the incremental effect of a single user (or all the https everywhere users!) using https is incredibly tiny. It's not as cpu-intensive as many people think. Unless a corporation is breaking ssl ( like in this case - http://superuser.com/questions/115349/firefox-this-connection-is-untrusted-behind-corporate-firewall ) their proxies would be unable to cache SSL content. If you're curious about wikimedia's architecture, you can check it out on our wiki -- https://wikitech.wikimedia.org/wiki/Main_Page Leslie > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 >
Re: Problem reaching Wikipedia (AS43821) via Tele2
I should really look at NANOG more ;) All of our whois information is up to date, our peeringdb information is up to date, and the usual generic email of n...@wikimedia.org also works. We also have a few irc channels, bugzilla, and a technical problem wiki page! If anyone has issues reaching AS43821 or AS14907 , please contact us directly if you want it fixed sooner than once a week :) Leslie (Wikimedia Foundation - you can also contact me at lc...@wikimedia.org for any official business). P.S. If anyone's curious, Tele2 was fine - there was an issue between two other as's on a different return path. Hence the * * * after hopping into our network post-border router. On Fri, May 3, 2013 at 2:30 AM, Israel G. Lugo wrote: > Indeed, although I wouldn't know why. > > The problem lasted the whole day yesterday, but it seems to be gone now. > I was given the tech contact for Wikimedia off-list; if anything rises > up again I'll get in touch with them. > > Thank you for the reply, and also to everyone who replied off-list. > > Regards, > Israel G. Lugo > > On 05/02/2013 07:08 PM, Grant Ridder wrote: >> Looks like ge-2-5.br1-knams.wikimedia.org (130.244.6.250) is filtering you >> somehow. >> >> Grant >> >> Sent from my iPhone >> >> On May 2, 2013, at 9:01 AM, "Israel G. Lugo" wrote: >> >>> Hello, >>> >>> Anyone else having problems reaching Wikipedia? >>> >>> I can't reach AS43821 (Wikimedia RIPE) from within the Portuguese NREN >>> (AS1930), via Cogent (AS174) -> Tele2 (AS1257): >>> >>> traceroute to en.wikipedia.org (91.198.174.225), 30 hops max, 60 byte >>> packets >>> 1 Router3.10GE.Lisboa.fccn.pt (193.136.1.89) [AS1930] 0.953 ms >>> 2 ROUTER10.10GE.Lisboa.fccn.pt (193.137.0.8) [AS1930] 0.939 ms >>> 3 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) [AS1930] 1.000 ms >>> 4 fccn.mx2.lis.pt.geant.net (62.40.124.97) [AS20965] 1.000 ms >>> 5 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) [AS20965] 13.926 ms >>> 6 as2.rt1.gen.ch.geant2.net (62.40.112.25) [AS20965] 37.882 ms >>> 7 ae3.mx1.gen.ch.geant.net (62.40.112.14) [AS20965] 37.874 ms >>> 8 ae1.mx1.fra.de.geant.net (62.40.98.109) [AS20965] 44.154 ms >>> 9 ae4.rt1.fra.de.geant.net (62.40.98.135) [AS20965] 43.935 ms >>> 10 te0-4-0-2.mag21.fra03.atlas.cogentco.com (149.6.42.73) [AS174] >>> 44.842 ms >>> 11 fra36-peer-1.xe-1-2-0-unit0.tele2.net (130.244.200.41) [AS1257] >>> 44.368 ms >>> 12 fra36-core-1.bundle-ether2.tele2.net (130.244.64.186) [AS1257] >>> 44.977 ms >>> 13 * >>> 14 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) [AS1257] 50.299 ms >>> 15 * >>> 16 * >>> 17 * >>> 18 * >>> 19 * >>> 20 * >>> >>> Tele2's traceroute server (http://services.tele2net.at/traceroute.html) >>> reaches the same IP without problems: >>> >>> 1 213.90.34.4 (213.90.34.4) 0.268 ms 0.124 ms 0.151 ms >>> 2 213.90.1.20 (213.90.1.20) 0.430 ms 0.382 ms 0.303 ms >>> 3 wat1-15-93.net.uta.at (62.218.15.93) 0.497 ms 0.368 ms 0.387 ms >>> 4 c76wmode1-tengigE4-1.net.uta.at (212.152.192.206) 0.644 ms 0.572 ms >>> 0.599 ms >>> 5 wen1-core-2.tengige0-0-1-1.tele2.net (130.244.205.57) 0.836 ms 0.874 >>> ms 0.737 ms >>> 6 fra36-core-1.bundle-ether7.tele2.net (130.244.206.28) 13.683 ms 13.472 >>> ms 13.817 ms >>> 7 ams-core-2.bundle-ether4.tele2.net (130.244.64.201) 20.421 ms 20.482 >>> ms 20.762 ms >>> 8 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) 19.972 ms 19.936 ms >>> 19.962 ms >>> 9 ge-2-5.br1-knams.wikimedia.org (130.244.6.250) 20.727 ms 20.641 ms >>> 20.660 ms >>> 10 wikipedia-lb.esams.wikimedia.org (91.198.174.225) 20.610 ms 20.539 ms >>> 20.615 ms >>> >>> Trying from $HOME_ISP, via AS6453 (Globe) -> AS1299 (Telia) works fine. >>> >>> Regards, >>> Israel G. Lugo >>> >>> > >
