Subject: [75attendees] rica network

From: Randy Bush <[email-masked]>
Date: Fri, 24 Jul 2009 15:58:36 +0200

in room wireless at the rica is notable.  occasionally many minute long
spans of

rmac.local:/Users/randy> ping rip
PING rip.psg.com (147.28.0.39): 56 data bytes
64 bytes from 147.28.0.39: icmp_seq=7 ttl=57 time=18370.545 ms
64 bytes from 147.28.0.39: icmp_seq=8 ttl=57 time=18587.562 ms
64 bytes from 147.28.0.39: icmp_seq=18 ttl=57 time=27734.774 ms
64 bytes from 147.28.0.39: icmp_seq=23 ttl=57 time=37926.666 ms
64 bytes from 147.28.0.39: icmp_seq=25 ttl=57 time=47189.189 ms
64 bytes from 147.28.0.39: icmp_seq=26 ttl=57 time=72693.296 ms
64 bytes from 147.28.0.39: icmp_seq=32 ttl=57 time=71583.252 ms
64 bytes from 147.28.0.39: icmp_seq=51 ttl=57 time=64048.341 ms
64 bytes from 147.28.0.39: icmp_seq=52 ttl=57 time=67393.162 ms
64 bytes from 147.28.0.39: icmp_seq=128 ttl=57 time=8380.909 ms
64 bytes from 147.28.0.39: icmp_seq=129 ttl=57 time=18094.450 ms
64 bytes from 147.28.0.39: icmp_seq=130 ttl=57 time=24929.447 ms
64 bytes from 147.28.0.39: icmp_seq=131 ttl=57 time=33823.830 ms
64 bytes from 147.28.0.39: icmp_seq=132 ttl=57 time=46342.897 ms
64 bytes from 147.28.0.39: icmp_seq=133 ttl=57 time=47345.784 ms
64 bytes from 147.28.0.39: icmp_seq=134 ttl=57 time=53753.028 ms
64 bytes from 147.28.0.39: icmp_seq=135 ttl=57 time=55274.362 ms
64 bytes from 147.28.0.39: icmp_seq=136 ttl=57 time=61025.613 ms
64 bytes from 147.28.0.39: icmp_seq=137 ttl=57 time=74460.338 ms
64 bytes from 147.28.0.39: icmp_seq=138 ttl=57 time=84770.199 ms
64 bytes from 147.28.0.39: icmp_seq=139 ttl=57 time=101473.587 ms
64 bytes from 147.28.0.39: icmp_seq=140 ttl=57 time=108275.138 ms

randy

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 24 Jul 2009 15:09:43 +0100

At Friday 24/07/2009 15:58 +0200, Randy Bush wrote:
>in room wireless at the rica

Which Rica? There are two: Rica Stockholm and Rica Kungsgatan.

>  is notable.  occasionally many minute long
>spans of
>

---

From: Scott Brim <[email-masked]>
Date: Fri, 24 Jul 2009 16:11:43 +0200

> 64 bytes from 147.28.0.39: icmp_seq=7 ttl=57 time=18370.545 ms

...

I'm now at Rica Kungsgatan and a 20-ping test gets

round-trip min/avg/max/stddev = 184.547/225.248/365.612/52.678 ms

I don't think it's been much worse, I've been on VoIP-over-VPN calls
this afternoon without serious trouble.

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 24 Jul 2009 10:18:33 -0400 (Eastern Daylight Time)

> this afternoon without serious trouble.

I was getting good response, then suddently I couldn't resolve dns names 
-- no answer from server.  and the dns servers weren't responding to 
pings.

Seems better now.

--Sandy

> _______________________________________________
> 75attendees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/75attendees
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Jul 2009 20:12:52 +0200

> 64 bytes from 147.28.0.39: icmp_seq=7 ttl=57 time=18370.545 ms

I always wonder what it is that IETF-goers do that creates so much  
data traffic that it brings down hotel networks but doesn't back off  
at that point.

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 24 Jul 2009 19:15:31 -0400

> data traffic that it brings down hotel networks but doesn't back off

Lots of UDP video or filesharing ?

Regards
Marshall

Marshall Eubanks
CTO / Iformata Communications
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Jul 2009 16:23:45 -0700

> Lots of UDP video or filesharing ?

I always suspect Skype, but I don't know how realistic that is.   Most of the really bandwidth-intensive protocols on the Internet either use multiple TCP streams to get more than their fair share of the bandwidth, or use UDP (which means they still *could* implement TCP-like congestion detection, but aren't forced to, and would have to go to a great deal of trouble to do so).

I suspect that most of the video applications actually use TCP streams - e.g., doesn't YouTube just use straight flash video over a single TCP/IP connection?   This would be subject to congestion control, and thus ought to share bandwidth fairly well with you.

Of course, ping has no congestion control, so perhaps Randy is the real culprit here...   ;')

---

From: Morgan Sackett <[email-masked]>
Date: Sat, 25 Jul 2009 13:22:43 +0200

are you on a wire, or over the air?  Could just be a crummy AP that  
doesn't handle poorly connected clients well.

> 64 bytes from 147.28.0.39: icmp_seq=140 ttl=57 time=108275.138 ms

Morgan Sackett
VP of Engineering

VeriLAN Event Services, Inc.
215 SE Morrison Street
Portland, OR 97214

Tel: 503 907-1415
Fax: 503 224-8833

[email-masked]
www.verilan.com

This e-mail contains proprietary information and may be confidential.  
If you are not the intended recipient of this e-mail, you are hereby  
notified that any dissemination, distribution or copying of this  
message is strictly prohibited. If you received this message in error,  
please delete it immediately.

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Jul 2009 14:27:51 +0200

>> 64 bytes from 147.28.0.39: icmp_seq=140 ttl=57 time=108275.138 ms

wireless.  but the connection was often quite reasonable

64 bytes from 147.28.0.39: icmp_seq=60745 ttl=57 time=174.778 ms
64 bytes from 147.28.0.39: icmp_seq=60746 ttl=57 time=172.364 ms
64 bytes from 147.28.0.39: icmp_seq=60747 ttl=57 time=177.760 ms
64 bytes from 147.28.0.39: icmp_seq=60748 ttl=57 time=176.990 ms
64 bytes from 147.28.0.39: icmp_seq=60749 ttl=57 time=174.943 ms
64 bytes from 147.28.0.39: icmp_seq=60750 ttl=57 time=175.085 ms
64 bytes from 147.28.0.39: icmp_seq=60751 ttl=57 time=176.946 ms
64 bytes from 147.28.0.39: icmp_seq=60752 ttl=57 time=177.268 ms
64 bytes from 147.28.0.39: icmp_seq=60753 ttl=57 time=175.193 ms
64 bytes from 147.28.0.39: icmp_seq=60754 ttl=57 time=175.453 ms
64 bytes from 147.28.0.39: icmp_seq=60755 ttl=57 time=175.040 ms
64 bytes from 147.28.0.39: icmp_seq=60756 ttl=57 time=176.952 ms
64 bytes from 147.28.0.39: icmp_seq=60757 ttl=57 time=176.603 ms
64 bytes from 147.28.0.39: icmp_seq=60758 ttl=57 time=173.528 ms

---

From: Morgan Sackett <[email-masked]>
Date: Sat, 25 Jul 2009 14:46:55 +0200

Yeah, that's the thing about that particular second layer.  The driver  
has no way to tell if the AP is actually processing the frames well or  
not, so only gives feedback based on the relative SNR.  The channel  
can in fact be completely loaded and you will still seem to have a  
good connection.  Easily solved by trying to ping your gateway, as  
hopefully it's not the device that's loaded, and even if the uplink is  
borked, the internal interface should be nice and responsive.  If you  
still get crazy high latency, it's likely that it's the AP and not the  
upstream.

Morgan Sackett
VP of Engineering

Tel: 503 907-1415
Fax: 503 224-8833

[email-masked]
www.verilan.com