Subject: Re: [vmeet] Fwd: I-D ACTION:draft-ietf-genarea-rps-reqs-05.txt

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 02 Aug 2012 12:53:09 -0700

Some comments below:

On 07/30/2012 09:31 AM, Robert Sparks wrote:
> Some comments on -05:
> 
> Could we change the sentence in 05-04 that starts "When possible, the 
> delivery SHOULD" to "The system MUST minimize internal latency, should 
> avoid unnecessary architectural latency, and be designed with a goal of 
> having less than 200 milliseconds of delay to remote attendees who are on 
> fast Internet connections."

I think that this change from SHOULD to MUST would have a better chance to
match (future) reality if my proposal to separate the requirements between
participating and non-participating remote attendees was taken in account.
Here's what I said in a previous review:

"I think that these requirements should be relaxed for remote attendees that do
not plan on contributing (i.e. that did not register).  If one has no
intention to comment, it does not matter what the delay is (it still need to
be reasonable, i.e. < 15 seconds).  Removing this constraint would probably
permit to better serve the smaller group of remote attendees who signaled that
they plan to participate by registering."

> 
> Could we change requirement 05-06 to "Many attendees will be in places
> with limited bandwidth. Remote attendees on 56Kbps Internet connections
> SHOULD be able to receive useable versions of all streaming information.
> The system SHOULD take advantage of higher bandwidth audio and video
> encodings for participants on higher bandwidth connections. The system MUST
> NOT architecturally prevent the use of higher bandwidth encodings."
> 
> Requirements like 05-10 assume the system has to know the difference 
> between registered and unregistered participants, but there's no clear 
> requirement for the software to make this distinction. Can we add a 
> requirement that makes it clear to a software developer that this is our 
> intent?
> 
> Do we want a requirement bounding how long it takes to register to 
> participate remotely? If someone who thought they would be listening only 
> (as described in 05-11) discovers they need to send a text message to ask 
> for clarification, will they be able to negotiate getting registered and 
> convincing the software that they are registered before the session they 
> are listening to concludes?

Req 05-12 already says that registration has to verify an email address, so it
seems difficult to add a requirement for how long it will take, knowing that
one can be listening on a device that do not have email access at the time one
changes its mind.  Slow emails delivery and spam filters also can make this
difficult to manage.

> 
> In Requirement 05-12, are you assuming the passwords provided are unique
> to the registration? Is the intent to prevent one person from registering
> and sharing that password with many people? If so, is there a requirement
> on the software to restrict the use of that password to only one (or a
> small number) of places at a time? Alternatively, why aren't we just
> reusing datatracker logins here?
> 
> Is Requirement 05-23 intended to apply to each attendee independently? (Or 
> would having one volume knob for the entire mixed audio feed satisfy this 
> requirement?)

I think controlling individual streams has its usage.

> 
> In Requirement 05-31, how long do you want the "short text string" to be? 
> Is 10 characters enough? Is this intended to be arbitrary text provided by 
> the remote participant, or should they be choosing between a set of 
> pre-configured options?

Or both.

> 
> Could we delete 05-32 and add "It is not acceptable to simply rely on 
> humans reading instant messages to allow remote participants to make the 
> request for attention." to the end of 05-31? That appears to be what 05-32 
> is really intending to prevent.
> 
> 05-35 and 05-23 appear redundant?
> 
> Is there anything special to call out about working groups that have 
> multiple sessions during a meeting week? Are there any requirements on the 
> tool (particularly around archiving) to combine these sessions into some 
> logical unit associated with the working group? How much integration with 
> the meeting schedule information are you expecting? Should there be 
> explicit requirements to tie into that data store as input (the way the 
> week view at <datatracker.ietf.org/meeting/84/agenda> does for example).
> 

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: John Leslie <[email-masked]>
Date: Thu, 2 Aug 2012 22:29:35 -0400

> On 07/30/2012 09:31 AM, Robert Sparks wrote:

   In general, I wish to support Robert's suggestions, but Marc has some
good points.

>> fast Internet connections."

   I don't know how difficult that 200 msec target will be; but I do note
that some participants will be over 10,000 miles away, and "fast" Internet
connections sometimes have 50 msec last-hop delay. I would prefer to
target about 100 msec for packets to leave the actual servers bound for
the participant. (I'm quite soft on whether 100 msec is the right target.)

> "I think that these requirements should be relaxed for remote attendees
> that do not plan on contributing (i.e. that did not register). If one
> has no intention to comment, it does not matter what the delay is

   (I had interpreted the language to only apply to "participants".)

> (it still needs to be reasonable, i.e. < 15 seconds).

   15 seconds is painfully long, but I don't think we mean to constrain
this number for mere listeners.

> Removing this constraint would probably permit to better serve the
> smaller group of remote attendees who signaled that they plan to
> participate by registering."

   I can't recall a recent IETF-week where there wasn't sufficient
outgoing bandwidth to serve hundreds of participant streams.

>> encodings for participants on higher bandwidth connections. The system
>> MUST NOT architecturally prevent the use of higher bandwidth encodings."

   Just a few bits of wordsmithing:

- s/all streaming information/streaming information/
  At 56kbps, I would want to select the most important streams.

- s/prevent the use of/prevent other users from selecting/

>> requirement that makes it clear to a software developer that this is
>> our intent?

   (Agree.)

> Req 05-12 already says that registration has to verify an email address,
> so it seems difficult to add a requirement for how long it will take,
> knowing that one can be listening on a device that do not have email
> access at the time one changes its mind. Slow emails delivery and spam
> filters also can make this difficult to manage.

   I agree with Marc it's hard to set such limits.

>> reusing datatracker logins here?

   Good questions!

> I think controlling individual streams has its usage.

   I can imagine cases where the chair would want to enable two remote
attendees to interrupt each other: s/he would need individual volume
controls to make this work well.

>> the remote participant, or should they be choosing between a set of 

   Hmm...

   10 characters is rather limiting... I would have interpreted "short"
to mean something under 72 characters. Paul's examples outline the sort
of things one might type -- it would help some folks if there were a
pull-down list to choose from...

>> is really intending to prevent.

   5-32 is perhaps overly strong using "MUST"; but I think there needs
to be a mechanism separate from the jabber stream. I guess I'd let Paul
keep 5-32 but suggest it's perhaps shy of a MUST that the mechanism be
"part of the floor control tool".

>> 05-35 and 05-23 appear redundant?

   True... I think Paul had in mind the difference between limiting
volume and removing the user to reduce clutter.

>> week view at <datatracker.ietf.org/meeting/84/agenda> does for example).

   I don't agree any of this needs to be part of the tool. These sound
like human-intensive task better done by the Secretariat or volunteers
appointed by the WGCs.

--
John Leslie <[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Aug 2012 10:10:32 -0700

More comments on any of Robert's proposals are welcome.

--Paul Hoffman

---

From: Robert Sparks <[email-masked]>
Date: Thu, 09 Aug 2012 17:47:32 -0500

On 8/2/12 2:53 PM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Some comments below:
>
The only issue I see with this is synchronizing with any slide 
presentation. Having
additional latency for "read-only" users would be acceptable as long as 
the latency
was the same across all streams.
> changes its mind.  Slow emails delivery and spam filters also can make this
Well, that's pretty much my point. We should make it clear that if 
someone wants
to ask "what did they just say" they're going to have to register in 
advance or risk
not being able to ask in a timely fashion. That will cut into any 
advantage you might
get from having separate pools of registered vs unregistered participants.
> I think controlling individual streams has its usage.
And I think that was the intent - it just needs to be made clearer.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJQGtqhAAoJECnERZXWan7EqgkP/jtaUpVqVd0DimwgdpW4WmSN
> yWzdMCgljYkGt9WWFnRCfOJAzQWCGCQGmsGuk+AVQT7H8Yhvk0S9t1ldZKqVhgrB
> Fm0pYMYf4ejplYr29WcKYtn7HaX8aE+PaV1d+CxNZmoHSWDYu9Xqzmpd5VFUzSsi
> URQuDaU/Qp1NJxMMl4WbEDnfkLco7+WxzRXRu7iQVLrj0MMeJyYAEIHv0WvtaQ06
> oW953fkqDP0OyMkXVmK1/IbUQJlEUYsdamwUcDNAcDOEk95s2ACsUO12YQ5V2Jta
> V7R3GVn/fGJqtqizXuFKP50vYTwY87FdTwvUH11TskU1KMzZMIPwP05hm6oNme3H
> Wb1M9xgSmHWzqK6i0fGLC7hIPAKv/QMvJ3r8vfdoZSIZwvNES24deWfQBHrlxIyK
> jIozFqgNcbyFHoSs+u0pk8ArqEiCjB+RNKwMBxTvwsEti/qvfNZf/D4oLSqQOsut
> JqZ1zkepSc9Be0l4lItLjZnQ5xTkbZiHHIoCJ36dZxEspLMHCBMPEUQC3r+DvqyE
> VRIdIYeWXlMB3lK7USzTMJg2UV8oxdBztfvwp+wpNG384JbKBSEIfaYsbVNAocP6
> gUT94rmWMMnB2aM71QDaiIibJVp4KISj1+r+0t82wiFSzU17b8R5/DMGVy6VEnPe
> HsnHmjiEi/GTwfisEI4R
> =W4yd
> -----END PGP SIGNATURE-----

---

From: Robert Sparks <[email-masked]>
Date: Thu, 09 Aug 2012 17:57:37 -0500

> the participant. (I'm quite soft on whether 100 msec is the right target.)
You are suggesting a more concrete definition of "unnecessary 
architectural latency".
I think we'll get a better result if we push for that to be as small as 
we can make it, rather
than try to explicitly create a budget for internal latency vs 
transmission latency.
>    At 56kbps, I would want to select the most important streams.
Agreed, but you should still be able to get something usable if you 
asked for all
the streams (but almost certainly not as nice as you would get if you 
limited the
input to what you considered important).

Do we have a requirement captured somewhere to let a remote participant 
_choose_
which streams to receive if multiple streams are available? On a fast 
skim, I'm not finding
it (though it could be inferred from the text after 05-52.
> - s/prevent the use of/prevent other users from selecting/
wfm
> pull-down list to choose from...
Paul - is this enough to build some clarifying text with?
> like human-intensive task better done by the Secretariat or volunteers
We should at least keep an eye towards making it easy for the 
secretariat or volunteers.