Subject: [67ATTENDEES] Anyone get the 'broadband' connection in the IETF hotel

From: <[email-masked]>
Date: Wed, 8 Nov 2006 00:05:46 +0200

>-----Original Message-----
>From: ext [email-masked] 
>[mailto:[email-masked]] 
>Sent: 08 November, 2006 00:00
>To: Loughney John (Nokia-NRC/Helsinki)
>Subject: Welcome to the "67ATTENDEES" mailing list
>
>Welcome to the [email-masked] mailing list!
>
>To post to this list, send your email to:
>
>  [email-masked]
>
>General information about the mailing list is at:
>
>  https://www1.ietf.org/mailman/listinfo/67attendees
>
>**********************************************************************
>
>                                Note Well
>
>Any submission to the IETF intended by the Contributor for 
>publication as all or part of an IETF Internet-Draft or RFC 
>and any statement made within the context of an IETF activity 
>is considered an "IETF Contribution".  Such statements include 
>oral statements in IETF sessions, as well as written and 
>electronic communications made at any time or place, which are 
>addressed to:
>
>     - the IETF plenary session,
>     - any IETF working group or portion thereof,
>     - the IESG, or any member thereof on behalf of the IESG,
>     - the IAB or any member thereof on behalf of the IAB,
>     - any IETF mailing list, including the IETF list itself, any
>       working group or design team list, or any other list
>       functioning under IETF auspices,
>     - the RFC Editor or the Internet-Drafts function
>
>All IETF Contributions are subject to the rules of RFC 3978 
>(updated by RFC 4748) and RFC 3979.
>
>Statements made outside of an IETF session, mailing list or 
>other function, that are clearly not intended to be input to 
Hi all,

Sunday night and Monday morning, I wanted to get some work done in my
room, but found the in-room network kept timing out on the login screen.
I talked to a few people who reported the exact same thing. Anyone else
actually get the in-room connection working?

thanks,
John

_______________________________________________
67ATTENDEES mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/67attendees

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 08 Nov 2006 07:14:59 +0900

> actually get the in-room connection working?

Yes, it works for me except that it is very slow especially
around mid-night.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 7 Nov 2006 17:18:56 -0500

Yes, on the first floor it has worked Sunday night through today.

On sending a large file, I had a sustained bandwidth of about 30  
Kbps, so
it took a long while.

You have to sign up first - you might want to remove any hard-wired  
DNS servers from your
Internet configuration to get that to work.

Regards
Marshall

---

From: "Clint Chaplin" <[email-masked]>
Date: Tue, 7 Nov 2006 14:19:01 -0800

I'm doing sorta OK, but I'm running ZoneLabs firewall, and the system
keeps trying to open a connection with my computer, and the firewall
refuses it.  No timeouts, but lots of annoying firewall alerts.

-- 
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 07 Nov 2006 17:22:25 -0500

John,

Yes, I've used it the last two evenings/mornings and while it's 
functional for email and surfing, you wouldn't want to try streaming 
video over it.

I remember fondly those IETFs (like Salt Lake City) where the IETF 
network was available in all of the guest rooms.

Now that we're going to be sticking with a single hotel chain 
starting in Prague, perhaps we can work with their central 
organization to obtain more consistent in-room networking.

Cheers,
Andy

----------

---

From: Yi Zhao <[email-masked]>
Date: Tue, 07 Nov 2006 16:22:58 -0600

It works. You need to launch the browser and login as a hotel guest. It
shows $11 something for 24 hours but actually the hotel will wave the charge
for IETF attendees (I called the front desk and was told so).

Yi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 2006年11月7日 16:06
To: [email-masked]
Subject: [67ATTENDEES] Anyone get the 'broadband' connection in the IETF
hotel

Hi all,

thanks,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Nov 2006 09:41:30 +1100

> actually get the in-room connection working?

	Yes.  Using it right now.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 Nov 2006 01:57:05 +0100

Hi,

> It works. You need to launch the browser and login as a hotel guest. It

I experienced problems (500 Internal Server Error) using FireFox as a
Browser
when trying to log in. Using a different Browser helped as workaround.
However, in terms of performance you are better off with the IETF
net.

Regards,
 Roland

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Nov 2006 12:43:51 -0800

So you may find this interesting. Last night, at 6:30, I started a  
ping study from my room to a computer back at "the ranch". You may  
look at the pictures at
	ftp://ftpeng.cisco.com/fred/sheraton/ping-study-11-7-rtt.htm

There are two charts, one of the ping RTT distribution, and one of  
the per-minute minimum, average, maximum, standard deviation, and  
percentage of loss. You flip between them (yes, this was done using  
Excel) by clicking on "chart1" and "chart2". The second is displayed  
on a log-linear chart, because the upper bound value is a 35 second  
RTT on a ping that happened a bit after 11:00 last nightand it would  
be really nice to be able to see the normal samples, which are in the  
60-500ms range. The delay distribution chart is interesting in this  
way: the 90% confidence delay is shown in the chart; the last 10% has  
samples, as I said, all the way from 750 ms to 35 seconds. But  
instead of the typical Poisson distribution in which 90% of cases are  
within zero and twice the mean, there is a big bump around the mean  
and a really long and pronounced tail in which there is a very high  
probability that delay on a packet is many times the mean RTT. I  
would guess that your average TCP is probably unnecessarily  
retransmitting a significant percentage of its transmissions simply  
because of wildly varying delay.

Basically, last night, there was a significant delay bump from 10:00  
PM to 1:30 AM and another one from about 6:00 AM to 8:00 AM.  
Surprise. 10:00 is about when we got back from the social, dinner, or  
whatever else we did last night, and 6:00-8:00 is when we are all in  
our rooms and haven't yet materialized downstairs for coffee.

Something about having 1000 internet geeks walk into a hotel that is  
designed for executive travelers and wonder what's happening back  
home :-)

---

From: Simon Leinen <[email-masked]>
Date: Wed, 8 Nov 2006 16:06:21 -0800

>       ftp://ftpeng.cisco.com/fred/sheraton/ping-study-11-7-rtt.htm

Cute, thanks!

My laptop is permanently monitored using Tobi Oetiker's SmokePing
tool, which has another nice way of visualizing delay distributions
(loss is also displayed, by the color of the median line):

http://lg.net.switch.ch/cgi-bin/smokeping.cgi?target=World.Europe.Switzerland.Simon.Laptop

The measurement server is in Switzerland, so the base RTT is >160ms
(and timescale is based on Central European Time).

> [...] The second is displayed on a log-linear chart, because the
> upper bound value is a 35 second RTT on a ping that happened a bit
> after 11:00 last night

Sudden load increase as busloads of IETFers returning from the
(excellent) social were unloaded onto the poor hotel network?

> and it would be really nice to be able to see the normal samples,
> which are in the 60-500ms range. The delay distribution chart is
> interesting in this way: the 90% confidence delay is shown in the
> chart; the last 10% has samples, as I said, all the way from 750 ms
> to 35 seconds. But instead of the typical Poisson distribution in
> which 90% of cases are within zero and twice the mean, there is a
> big bump around the mean and a really long and pronounced tail in
> which there is a very high probability that delay on a packet is
> many times the mean RTT. I would guess that your average TCP is
> probably unnecessarily retransmitting a significant percentage of
> its transmissions simply because of wildly varying delay.

Right.  This would argue for tuning the network differently, namely
for shorter queues, possibly (but not necessarily) at the expense of
higher loss.  Sounds like an excellent place for RED (remember RED?),
but even with tail-drop and just smaller buffer limits in some router,
it would probably work better for most if not all users.  If someone
has contacts with the operator of the congested part of the backbone
(AT&T?), I wouldn't mind talking to them...

> Surprise. 10:00 is about when we got back from the social, dinner,
> or whatever else we did last night, and 6:00-8:00 is when we are all
> in our rooms and haven't yet materialized downstairs for coffee.

> designed for executive travelers and wonder what's happening back  

I can easily imagine that this type of behavior "trickles down" to the
non-geek traveler population.
-- 
Simon.