Subject: IETF Connectivity and Terminal Room

From: Daniel Senie <[email-masked]>
Date: Wed, 24 Mar 1999 08:57:06 -0500

I was unable to make the Minneapolis meeting and wound up trying to
attend some sessions over the 'net. I'd like to share some observations
about that, and about terminal rooms past.

Much effort goes into setting up Mbone feeds, cameras and producing the
live video coverage. I hope someone gets to see it. I found it difficult
to impossible to watch. Many folks can't get actual Mbone feeds at this
point. Lots of ISPs don't provide multicast (some don't seem to know
what it is).

A RealVideo feed was provided off of one Mbone channel only. Invariably,
the meetings I needed to hear were on the other channel. Even the one
channel provided didn't work well. More often than not, there was
network congestion near where the session was being encoded. It appeared
that RealNetworks was encoding the session at their site, taking data
from the Mbone feed. The congestion problems were occurring at or very
near the RealNetworks encoding point, based on my testing. If we're
going to bother with the expense and effort of the live feeds, expanding
the usability of that resource should be a goal. Using RealVideo,
Netmeeting, or other methods which can operate without Mbone helps this.
Of course if we could get ISPs to provide multicast, that'd help too.

At the start of last week, there was no information on the availability
of non-Mbone feeds. After a number of conflicting emails about where to
look, I finally did get some feeds, but they were spotty at best. A web
page was added to the IETF meetings page to give the info at some point
during the week. The RealVideo feeds kept getting turned off between
sessions, which was a MAJOR pain. It's unclear why the feeds weren't
just allowed to run morning 'til night. Between sessions, attempting to
connect resulted in a generic error message, which was quite unhelpful,
and made it look like the feed was broken, not just disabled.

On terminal rooms past:

The facilities at the IETF have been good for the most part over the
last several years. Improvements have been evident. In Memphis, we had a
few switches and a lot of hubs on tables for laptops. While adequate,
the setup in Los Angeles performed much better. The layout in Chicago
was problematic (insufficient elbow room and table space for laptop
connection stations) but otherwise was OK. In general, folks have done a
great job. There is a continuity problem in that lessons from one
meeting aren't always remembered by the next one.

I have offered to help with setup in the past, and been told everything
was covered, and no help was needed. When I attend IETF, I'm often there
early on Sunday, and so could spend some time helping. The response I
got seems to conflict with suggestions that folks provide help.

DHCP: DHCP, the protocol, does a good job of assigning addresses. DHCP
as implemented on NT does not do a good job when the number of stations
it is serving exceeds the number of IP addresses available. At the point
at which addresses are recycled, the server seems to bog down. Two
solutions to this are to provide a large enough address block for DHCP
so that laptops effectively get the same address for the whole week, or
use server software which can handle the load. Setting lease times too
long creates real problems as well. A lease time of 30 minutes or less
makes sense given the terminal room turnover.

Wireless: The wireless network should be a separate subnet, NOT bridged
to the rest. DHCP on the wireless should use longer lease times, as
stations tend to stay live longer. the DHCP zone for wireless should be
separate from the laptop network (obvious, since it's a separate
subnet). Expanded use of wireless should be encouraged, as it relieves
strain on the terminal room. The wireless cards are not overly
expensive. I bought one last year, solely for use at IETF meetings. I
would like to see even more access points, and would like to hear
suggestions for funding such.

Hotel Phone Capacity: While unrelated to the terminal room, someone
mentioned there'd be trouble with the telephone system in the hotel if
more folks had to rely on it for connections out. The hotel in Orlando
suffered from this problem. More often than not, when I placed a call
(voice or data) I got an all-circuits-busy from the PBX. Adding any more
load surely would have been a bad thing.

Overall, the terminal room is an essential element of the meetings. As
with many other folks, it would not be possible for me to attend were it
not for the connectivity of the terminal room. It's necessary for me to
be plugged in on a regular basis to deal with problems back home. I
appreciate the efforts folks have made in setting up the terminal rooms
and hope it'll continue.

Dan

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com

---

From: [email-masked] (Kevin C. Almeroth)
Date: Wed, 24 Mar 1999 09:59:20 -0800 (PST)

>>point. Lots of ISPs don't provide multicast (some don't seem to know

If you have multicast connectivity, you can always re-watch events at
http://imj.gatech.edu/  Connectivity is better from UCSB (don't ask,
but that's where the IETF videos are stored) than most IETFs simply
because I work hard to make sure we have a decent feed.  It is a little
harder to get low congestion tunnels set up in a matter of a couple of
days.

>>channel provided didn't work well. 

The Real stuff is being tried on a non-cost (to you at least) experimental 
basis.  If we can work out the kinks we are looking to make it part of the 
production service.  BTW, thanks to the Real folks for even attempting this.

>>and made it look like the feed was broken, not just disabled.

Again, please be gentle here...  the Real Networks stuff is still very
much an experimental effort.  Don't start shooting those who are trying
to improve service before they've had a chance to work on it.

-Kevin Almeroth

---

From: [email-masked] (Kevin C. Almeroth)
Date: Wed, 24 Mar 1999 09:59:20 -0800 (PST)

-Kevin Almeroth