Re: [78attendees] Lessons we can take from the Internet connectivity fiasco in Maastricht...

Iljitsch van Beijnum <iljitsch@muada.com> Wed, 28 July 2010 21:55 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: 78attendees@core3.amsl.com
Delivered-To: 78attendees@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E2B3A6885 for <78attendees@core3.amsl.com>; Wed, 28 Jul 2010 14:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.384
X-Spam-Level:
X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYikZzX6pZzE for <78attendees@core3.amsl.com>; Wed, 28 Jul 2010 14:55:09 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 223BD3A67C3 for <78attendees@ietf.org>; Wed, 28 Jul 2010 14:55:08 -0700 (PDT)
Received: from [10.122.30.2] ([80.187.219.18]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o6SLsoSx075020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Jul 2010 23:54:51 +0200 (CEST) (envelope-from iljitsch@muada.com)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <2172BD75-3FDD-4F4A-863F-59BA29B57048@nominum.com>
Date: Wed, 28 Jul 2010 23:55:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC771E58-E394-4C0A-A27F-DCC8FC5A7AE1@muada.com>
References: <2172BD75-3FDD-4F4A-863F-59BA29B57048@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1081)
Cc: "78attendees@ietf.org" <78attendees@ietf.org>
Subject: Re: [78attendees] Lessons we can take from the Internet connectivity fiasco in Maastricht...
X-BeenThere: 78attendees@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF 78 attendees list <78attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/78attendees>, <mailto:78attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/78attendees>
List-Post: <mailto:78attendees@ietf.org>
List-Help: <mailto:78attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/78attendees>, <mailto:78attendees-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jul 2010 21:55:20 -0000

On 28 jul 2010, at 22:17, Ted Lemon wrote:

> IETFers kill hotel networks dead.   It's something we should just accept.

While I sympathize with your ordeal (I sort of had one myself, with the data service on my Dutch SIM that I've had for years not working when I arrived back into the country and getting a new one at the store proved impossible) and I especially recognize the frustration and time suck that is the promise of connectivity working if I just do this, that or the other thing, I have to disagree with you.

There is a very good network at the venue. Nobody has to be without connectivity many non-sleeping, non-eating hours.

Why do IETFers kill hotel networks? I've had some experience where the congestion was unbelievable, at levels that couldn't have been caused by anything remotely resembling normal use. I very strongly suspect that some IETFers are doing things that no normal hotel network can handle. Since I don't do these things, I believe others can live without them, too. And then the hotel networks don't break and we can all be happy and the NOC can get some well deserved sleep.

So as the NH traffic is currently flowing through the IETF network: bring on the tcpdump, nmap and sflow and figure this thing out.

And: count your blessings. I was at a conference two months ago, where the venue network was so bad you couldn't even load the portal page during normal hours, only during breaks it was barely possible to download a few emails. In the hotel, the network only worked every other night. As in: at all. If the tech guy had left for the day without resetting the gateway there was no connectvity until the next day.