Subject: Re: [vmeet] meeting room resources

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 1 Apr 2009 09:36:12 -0500

Hi, Dave,

> Spencer Dawkins wrote:
>> One minor point that I'm not sure if people have thought about yet - I 
>> also brought a $400 netbook along on the trip, so that I could drive 
>> presentations and still have a working system available to check text in 
>> drafts, monitor the jabber conversation if someone said to look in the 
>> jabber room, etc. I don't know that I'd recommend this for everyone, but 
>> since I already have a netbook, I expect to bring it next time, too.
>
> Spencer, so the netbook was for the front-of-room, to collect and display 
> slides?
>
> And then you used your regular laptop for your own stuff?

exactly...

> I don't know if this is a path we want this group to walk down, but it's 
> probably worth asking whether having a laptop dedicated to each room --  
> along with a dedicated projector -- creates interesting changes in the 
> operation of a meeting?

I was mostly just letting people know what I was doing. I wouldn't DREAM of 
suggesting something like this in 2009, but the prices of netbooks are 
falling like everything else, I saw a number of people (JohnK, Elwyn, Dean) 
using EEE or Dell netbooks as their primary laptops during the meeting ... 
and I'm pretty sure that two netbooks would still be lighter than the 
laptops we were horsing around three years ago ;-)

Thanks,

Spencer

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 03 Apr 2009 05:52:24 -0700

Fred Baker wrote:
> At the recent IETF, I had three meetings (one of which I chaired) in 
> which remote participation would have really helped due to visa 
> problems. I did a thing with my cell phone and an in-room mike to 
> facilitate a remote presenter on Friday. It was a bit of a circus, but 
> it actually worked surprisingly well.
> 
> WebEx or equivalent would have been better.

(I'm mostly using Fred's posting as an excuse to try to trigger discussion of 
other Frames. /d)

Just to make clear:  The specific function that you added was a voice channel 
from one (or more) remote participants into the physical meeting room?

I assume this had a logical (presumably entirely manual) queuing mechanism, to 
insert the remote participant(s)' comments into the physical room's stream of 
discussion?

Were there any other value-add capabilities in this scenario?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 3 Apr 2009 12:20:59 -0400

I was the remote presenter - and it was similar to a conference call
from my end.  There were occasional collisions, but then there was
backoff and arbitration by the chair.  I had to talk loudly so people
could hear me, and sometimes the chair had to repeat questions from the
room so that I could answer them.  It was definitely ad-hoc, but it
worked - and we got a lot of useful work done.  Without two-way audio, I
would not have been able to present at this past IETF - so remote
presentation capability is becoming a must for some in this economy.

As a substitute for back-room meetings, we made a lot of phone calls -
it was clumsy and was slower, but in the end, we did end up
accomplishing what we needed to to make progress on the working group's
work item.

Physically attending IETF is always a better choice when possible - but,
unfortunately, it's not always feasible - and the work needs to continue
without it.

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dave CROCKER
Sent: Friday, April 03, 2009 8:52 AM
To: Fred Baker (fred)
Cc: [email-masked]
Subject: [vmeet] FRAME: Two-way voice

> WebEx or equivalent would have been better.

(I'm mostly using Fred's posting as an excuse to try to trigger
discussion of other Frames. /d)

Just to make clear:  The specific function that you added was a voice
channel 
from one (or more) remote participants into the physical meeting room?

I assume this had a logical (presumably entirely manual) queuing
mechanism, to 
insert the remote participant(s)' comments into the physical room's
stream of 
discussion?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Apr 2009 09:50:07 -0700

On Apr 3, 2009, at 5:52 AM, Dave CROCKER wrote:

> Just to make clear:  The specific function that you added was a  
> voice channel from one (or more) remote participants into the  
> physical meeting room?

I added a duplex audio channel of which we used one direction - mobile  
phones being what they are, the other wasn't all that useful.

> mechanism, to insert the remote participant(s)' comments into the  
> physical room's stream of discussion?

Yes. We had a highly sophisticated controller. His name was Fred :-)

In point of fact, the people in the room went way out of their way to  
include the remote speaker, probably because he was central to the  
conversation. We often have to remind people to use the mike; in this  
case, we didn't. There are several local discussants and two remote  
discussants in a conference room on one phone. People took pains to  
make the discussion clear and discuss things with the remote presenter.

> Were there any other value-add capabilities in this scenario?

No, and to be honest it wasn't what I would want it to be. I couldn't  
put the presenter in control of his slides, for example. The situation  
was that the authors had not been authorized to travel (Boston->SFO)  
on corporate money. One offered to fly on his own dime, and I thought  
we could work something out. This is what got worked out.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 03 Apr 2009 10:25:46 -0700

> Yes. We had a highly sophisticated controller. His name was Fred :-)

I believe there is some psych research that indicates acceptance of automated 
controls is greatly aided by personalizing it.  Not so sure the particular name 
was the best to choose.  Have to look for research on that...

> case, we didn't. 

It's clear that a sufficiently motivated group will put in extra effort to 
include remote participants.  That gives us an exemplar for the mode, but not a 
very good reference for how things should operator normally.  As a goal, we need 
to look for ways that "normally" works well enough on it own that we can take 
the group activity for granted.

> put the presenter in control of his slides, for example. 

What other features would you -- OR ANYONE ELSE ON THE LIST -- look for, as a 
basic increment to the current IETF meeting facilities for remote participants?

-- 

   Dave Crocker

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Apr 2009 11:16:38 -0700

On Apr 3, 2009, at 10:25 AM, Dave CROCKER wrote:
> As a goal, we need to look for ways that "normally" works well  
> enough on it own that we can take the group activity for granted.

Well, some form of floor control, in the sense of someone remote being  
able to "raise their hand", is very useful. However, if you don't have  
a virtual queue that a person standing at a mike understands that they  
are part of and understands their place in, you're looking at a human  
moderator. In my experience, a fair moderator is generally respected -  
if you were at the 6AI BOF last week, we had a long line of people at  
each of two mikes, and the chairs alternated between them by calling  
names. It worked. In plenaries, we have had relatively sophisticated  
algorithms like having new questions at one mike and followup on the  
current one at the others, and that has worked. People seem to be  
willing to play by whatever rules we set up if the rules are fair and  
the moderator is fair.

>> No, and to be honest it wasn't what I would want it to be. I  
>> couldn't put the presenter in control of his slides, for example.
>
> What other features would you -- OR ANYONE ELSE ON THE LIST -- look  
> for, as a basic increment to the current IETF meeting facilities for  
> remote participants?

I tend to think in terms of shared whiteboards, but that is more  
appropriate for smallish meetings. I think of ppt-or-equivalent as a  
replacement for a white board, with the advantage of pre-preparation  
and therefore thought.

Video, on the other hand, is optional to my view. People tend to be  
more engaged in meetings where video is in use, perhaps because they  
realize that other people can see them (although that can have issues, http://www.youtube.com/watch?v=S0pN_y9SCuM) 
. But headshot video is to me a waste of bandwidth, and pointing the  
camera at a slide projection is worse.

---

From: Doug Otis <[email-masked]>
Date: Fri, 3 Apr 2009 11:36:02 -0700

On Apr 3, 2009, at 9:50 AM, Fred Baker wrote:
> The situation was that the authors had not been authorized to travel  
> (Boston->SFO) on corporate money. One offered to fly on his own  
> dime, and I thought we could work something out. This is what got  
> worked out.

There are low cost and very small net-box computers under well $300,  
such as the Asus Eee Box B202 Desktop.  This contains 1.6 GHz Atom  
N270 processor, 1GB ram, 1Gb Ethernet, 802.11n wifi, DVI video, audio  
in/out, 160 GB hard drive, and Linux.

For example, using an ssh tunnel to the system can secure a connection  
to a VNC server or RDP for 1:1 control.  A secure ssh tunnel can be  
done on Windows using open source OS extensions.  There are also web  
based solutions.  A lab would be needed to would allow presenters and  
chairs to become familiar with connecting to and using remote desktops  
and the conferencing applications.

The net-box could run WebEx, BeeHive, EVO, or other conferencing  
applications.  By controlling the system using a remote desktop, the  
computer can remain next (glued) to the rooms digital projector, and  
yet be controlled by the meeting's chair at their desk, or by a remote  
presenter when control is passed to them.  The net-box device would  
need to be connected to the rooms network, audio output feed, as well  
as having speakers for remote audio.

-Doug

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 5 Apr 2009 19:16:11 -0400

> for, as a basic increment to the current IETF meeting facilities for  

More operations staff to make things actually work.

Every IETF meeting has a large number of a) attendees, b) potential  
remote attendee configurations, c) parallel tracks, and d) last minute  
schedule and room changes.  That's complex enough to require a small  
professional operations staff (most of it on-site) dedicated to e- 
meeting support.  These people will themselves need specialized tools  
-- the equivalent of "mixing boards" -- to help them keep the meetings  
running smoothly.

On-line participation could eventually increase the "attendee" count  
at least enough to cover the added costs, but this would clearly have  
a negative budget effect in the near term.

On Apr 3, 2009, at 2:16 PM, Fred Baker wrote:

> But headshot video is to me a waste of bandwidth, and pointing the  

The latter is as wasteful as it gets.  However...

In 1980, Carnegie Mellon's Computer Science Department upgraded  
graduate student offices so that we all had 4800 baud -- Hooray!   
Suddenly, everyone had enough bandwidth to see a demo of an ongoing  
research project involving a person-friendly networked menu-based user  
interface, boldly designed as if repainting a 24 by 80 character  
screen was simply no big deal.  A colleague (who shall remain  
nameless) watched this for a few seconds and declared, "this is the  
most obscene waste of bandwidth I have ever seen."

Headshot video clearly has *some* perceived value -- that is, many  
people, myself included, rate its utility as >0, even if barely  
so(*).   With some number of iterations of Moore's Law, any amount of  
utility will eventually justify any amount of bandwidth.  With video,  
I think we're already pretty near the tipping point.   -- Nathaniel

(*)The utility also surely differs from person to person.  Some people  
are very bad, for example, at reading emotions in voices, but have an  
easier time with faces.   It's also possible that seeing a person's  
face aids in forming long-term memory and perhaps a mental model of  
that person.   We're a very visual species; I wouldn't discount the  
value of video, if we ever figure out how to use it right.  -- nsb

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 6 Apr 2009 10:38:29 -0400

On Apr 5, 2009, at 7:16 PM, Nathaniel Borenstein wrote:

> With some number of iterations of Moore's Law, any amount of utility  
> will eventually justify any amount of bandwidth.

After a night's sleep and coffee, I can't resist another example that  
some of you will remember: back in the early 90's, as MIME  was being  
defined, I hand-composed a message in the new format that included a 6- 
second audio clip of me saying "Memory is cheap, bandwidth is  
cheaper."  Then, in a move that actually required me to screw up my  
courage, I sent the message to the entire MIME mailing list.  Of  
course, I was flamed by some for such an outrageous and deliberate  
waste of bandwidth, but most people got the point.

I think that as we consider the design of applications to support  
remote participation in IETF meetings -- or, really, networked  
applications in general -- we should do our very best to pretend that  
bandwidth is free and infinite.  The design space should be as  
unencumbered as possible, lest our imaginings miss a killer app out of  
fear of bandwidth scarcity, which seems like the kind of mistake that  
an organization of network engineers might be particularly likely to  
fall into.  When we find things that seem potentially useful, we  
should of course apply our best engineering practices to making them  
maximally efficient.  But our goal needs to be be better meetings, not  
bandwidth efficiency.   -- Nathaniel

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Apr 2009 08:41:44 -0700

On Apr 5, 2009, at 4:16 PM, Nathaniel Borenstein wrote:

> (*)The utility also surely differs from person to person.  Some  
> people are very bad, for example, at reading emotions in voices, but  
> have an easier time with faces.   It's also possible that seeing a  
> person's face aids in forming long-term memory and perhaps a mental  
> model of that person.   We're a very visual species; I wouldn't  
> discount the value of video, if we ever figure out how to use it  
> right.  -- nsb

Yes, I suppose. The thing it does most is make one feel that one is  
"there". Telepresence uses that fairly effectively by the other props  
they lay around the room - they make it *look* like everyone is around  
a common conference table. And feeling "there" probably helps one  
mentally be "there" as well.

The thing is that I am not generally looking at the headshot video; I  
am looking at the slide on the screen, or at the chat room.

So yes, when we learn to do it right it has value. What we have in  
headshot video isn't that.

I found your 1980 story amusing. In 1980, I was at Control Data, and  
the typical terminal given an engineer was 300 bps. That was a giant  
step up from a decade earlier at North American Rockwell; we had a  
2741 in the office, which I likely to use to write my programs. Other  
engineers complained that I should be paid keypunch operator wages, as  
the normal mode was to write code on coding forms and have it  
keypunched. But I digress. In 1981, a bunch of us marched on our  
manager's office and told him we wanted 9600 bps terminals. Control  
Data made me take a typing test - if I couldn't type 35 words per  
minute, they figured I couldn't effectively use a 9600 bps terminal.  
The point of a high bandwidth terminal, as I recall expressing it at  
the time, was not so that I could talk to the computer, it was so the  
computer could talk to me.

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Apr 2009 08:51:23 -0700

On Apr 6, 2009, at 7:38 AM, Nathaniel Borenstein wrote:

>> With some number of iterations of Moore's Law, any amount of  
>> utility will eventually justify any amount of bandwidth.
>
>
> After a night's sleep and coffee, I can't resist another example  
> that some of you will remember: back in the early 90's, as MIME  was  
> being defined, I hand-composed a message in the new format that  
> included a 6-second audio clip of me saying "Memory is cheap,  
> bandwidth is cheaper."  Then, in a move that actually required me to  
> screw up my courage, I sent the message to the entire MIME mailing  
> list.  Of course, I was flamed by some for such an outrageous and  
> deliberate waste of bandwidth, but most people got the point.
>
> applications in general -- we should do our very best to pretend  
> that bandwidth is free and infinite.  The design space should be as  
> unencumbered as possible, lest our imaginings miss a killer app out  
> of fear of bandwidth scarcity, which seems like the kind of mistake  
> that an organization of network engineers might be particularly  
> likely to fall into.  When we find things that seem potentially  
> useful, we should of course apply our best engineering practices to  
> making them maximally efficient.  But our goal needs to be be better  
> meetings, not bandwidth efficiency.   -- Nathaniel

Largely agreed. On the matter of sending large attachments (for some  
definition of "large"), the issue generally isn't the bandwidth used,  
it is the storage space consumed and the user download time (and the  
implied valuation or devaluation of other people's disk quotas and  
time when that happens). You haven't lived until you have been in an  
airport behind a relatively slow link, known that there was an email  
you needed to deal with at the tail of your queue, and had some joker  
send you a 10 Mbyte file as an attachment that you have to wait for  
before you can get the 10K email you are interested in. Fortunately  
mail applications now allow you to skip those and deal with them later.

I will amend your statement a tad, to say that we need to ignore  
bandwidth in our imaginings and then find practical ways to deal with  
the issues pragmatically. It's all well and good to say that everyone  
should be able to send, to pick on the video example, a 500 KBPS  
stream to everyone else simultaneously. Now let's imagine you have 300  
people doing that, one of which is you and the other 299 are sending  
you separate 500 KBPS video streams. If you don't have a problem with  
that, your IT department will. Pragmatically, I could see everyone  
sending a 500 KBPS video stream to an appropriate concentrator sending  
one video stream back.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 6 Apr 2009 12:12:47 -0400

On Apr 6, 2009, at 11:51 AM, Fred Baker wrote:

> bandwidth in our imaginings and then find practical ways to deal  
> with the issues pragmatically. It's all well and good to say that  
> everyone should be able to send, to pick on the video example, a 500  
> KBPS stream to everyone else simultaneously. Now let's imagine you  
> have 300 people doing that, one of which is you and the other 299  
> are sending you separate 500 KBPS video streams. If you don't have a  
> problem with that, your IT department will. Pragmatically, I could  
> see everyone sending a 500 KBPS video stream to an appropriate  
> concentrator sending one video stream back.

Agreed.  Often one comes up with a grand but barely-practical idea,  
and then finds that with enough engineering you can fake it.   This is  
a good example -- the idea is 300x300 video connectivity, while the  
implementation is a clever hack that gives most of the benefit of the  
idea at a fraction of the cost.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 09 Apr 2009 11:30:58 -0400

Nathaniel Borenstein wrote:
> we should do our very best to pretend that bandwidth is free 
> and infinite.  

Stated in this simple, direct and absolute form, I think this is exactly wrong, 
for this effort.

We are targeting an environment that will have extremely widespread use around 
the Internet, by people from parts of the nets and from organizations, with 
wildly different resources.  And the goal is to be as inclusive as possible 
(while still being reasonable; that is while still being able to get work done.)

And, by the way, as others have noted, bandwidth is only one of the factors. 
Throughput and delay are two of the others.  Each really is an independent 
factor.  Just as is timezone...

For certain kinds of narrowly-targeted services, yes it is better to assume no 
limits -- though I doubt anyone is likely to solve timezones.  Anyhow, we don't 
have that luxury, particularly because we are seeking currently available 
capabilities.

That's not to suggest that everything be designed for the least-common 
denominator, but what you've put forward is at the other extreme.  My point is 
that the targeted service should be considered much more carefully.

d/

-- 

   Dave Crocker

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Apr 2009 15:38:44 -0700

I find myself on both sides of this comment.

I think that Nathaniel is getting at "let's not make 'it has to be  
free' a priority that would preclude us from potentially-important  
options", and on that score I agree with him. When IP was designed  
with a 32 bit address, the line of reasoning common in the world was  
"every bit is expensive, let's only use as may bits as we really  
need", and IP (and Ethernet, with its 48 bit addresses and giant-at- 
the-time overheads, and CSMA assumptions) said "let's ignore that and  
see where it takes us". The world in 2009 is very different than it  
was in, say, 1972, and individual bits are no longer all that relevant.

What you are pointing out, I think, is well illustrated on the third  
slide of ftp://ftpeng.cisco.com/fred/Oxford/Oxford-fjb.pdf, which is a  
report I put together on IETF activity and the issues we are wrestling  
with in IPv6 deployment. The slide starts from a Telegeography cable  
map (found on the web) and points out the zone where the vast majority  
of IP addresses and IP connectivity is available. It's interesting  
talking with research people, all of whom seem to live in that zone; I  
had one ask not too long ago whether it was necessary to test TCP  
connectivity below 10 MBPS any more - "surely, nobody can buy a  
service slower than that, can they?" And the answer is that within  
that zone, megabits are a commodity, and outside that zone...

In October 2005, I visited Kabul. One morning, about 4:00 AM, the  
lights came on in my room, signaling that I once again had power for a  
little while. I turned on my computer, VPNed into Cisco, and started  
downloading my mail while I went back to bed. RTT was ~670 ms as I  
started, which is characteristic of geo-satcom, and my measured  
bandwidth was about 64 KBPS. I started a ping (as I often do) just to  
monitor performance, and found my ping delays starting at 670 ms and  
ramping up to O(several tens of seconds) [no, that's not a typo] for a  
period of four minutes. RTTs restored to single digit seconds for a  
while longer, and the power went off perhaps half an hour later.

A year earlier, I had been in Malawi. After a brief ceremony, they  
asked me to give a talk, and I pulled one out of my posterior. It  
happened to be on TCP and related network QoS behavior. When I was  
done, a gentleman identified himself as a representative of a local  
ISP, and asked me the implication of my statement that TCP didn't do  
well with loss rates above a few tenths of a percent. He explained  
that his ISP's practice was to provide random-rate radio links to  
their customers and drop traffic whenever the rate exceeded 64 KBPS. I  
suggested he try shaping instead of rate-limiting.

In India, two years ago, I observed someone running their laptop over  
GSM on their cell phone. That would be O(tens of KBPS).

...outside that zone, I might suggest that rate can be an issue.

And yes, loss rate and RTT can be an issue too.

On Apr 9, 2009, at 8:30 AM, Dave CROCKER wrote:

>> we should do our very best to pretend that bandwidth is free and  
>> infinite.
>
>
> Stated in this simple, direct and absolute form, I think this is  
> exactly wrong, for this effort.
>
> We are targeting an environment that will have extremely widespread  
> use around the Internet, by people from parts of the nets and from  
> organizations, with wildly different resources.  And the goal is to  
> be as inclusive as possible (while still being reasonable; that is  
> while still being able to get work done.)
>
> And, by the way, as others have noted, bandwidth is only one of the  
> factors. Throughput and delay are two of the others.  Each really is  
> an independent factor.  Just as is timezone...
>
> For certain kinds of narrowly-targeted services, yes it is better to  
> assume no limits -- though I doubt anyone is likely to solve  
> timezones.  Anyhow, we don't have that luxury, particularly because  
> we are seeking currently available capabilities.
>
> That's not to suggest that everything be designed for the least- 
> common denominator, but what you've put forward is at the other  
> extreme.  My point is that the targeted service should be considered  
> much more carefully.
>
> d/
>
> -- 
>
>  Dave Crocker