Subject: Re: [Dclc] Increasing RG meeting effectiveness

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 19 Aug 2014 15:37:18 +0000

I had a strange mail outage; I sent this a couple of days ago, and I see it neither in my own records nor on dclc@. Apologies if it’s a repeat.

Lars (IRTF Chair) sent the following a couple of weeks ago. We’re a poster child, and Lingli and I think the point is well taken.

We have had two meetings. One, at IETF-89, wasn’t widely announced. It happened in a small room with perhaps 20 chairs and as many people. Lingli showed a couple of slides, as did I, and we had a good general discussion. Our first “real” meeting was at IETF-90, in a room for 300 with construction noise and 39 scattered participants. A number of factors contributed, but the meeting was well described as a sequence of presentations with a little discussion after each.

Lars is suggesting meetings in places suited to the number of participants, in a discussion format. Sounds good to us. If that makes someone feel excluded, we obviously don’t want that, but we think this might be more inclusive anyway.

My suggestion for the moment is that people post what they like to the list, and if we have enough to have one, we can have a webex-or-whatever meeting. Otherwise, perhaps in October, we’ll ask what topics people would like to discuss f2f, and organize a meeting around a few topics.

On Aug 11, 2014, at 11:55 PM, Eggert, Lars <[email-masked]> wrote:

> Hi,
> 
> sorry for the length of this email.
> 
> I've been thinking about how we can increase the effectiveness of IRTF RG meetings during IETF weeks. My personal experience over the last few years is that RG meetings in very large IETF meeting rooms generally do not work well for many RGs.
> 
> These huge IETF rooms encourage a one-way pass-down of information from the speaker to the (silent) audience, and only a few participants (usually the same ones) making their way to the microphones to ask a few questions. It's usually impossible to have any sort of deeper or longer discussion under these circumstances.
> 
> I'm not saying that these classroom-style setups are wrong for all RGs - they may work well for some that operate more like academic workshops (e.g., NMRG), but they strike me as the wrong forum for RGs that need to operate differently in order to make progress.
> 
> As an example, I was struck by how much more effective the DCLC side meeting in London was, compared to the on-the-agenda meeting the proposed RG had in Toronto. In London, the meeting was in a boardroom-style arrangement with about 20 seats; in Toronto, it was in a huge IETF meeting room with a 300-seat classroom setup. 
> 
> Part of the reason was that in the small room in London, no microphones were used, and there were almost no presentations. It was a free-flowing discussion that was minuted and later continued by email. The Toronto meeting, in contrast, emulated an IETF WG meeting as many RGs are prone to do when meeting in IETF rooms: invited presentations, very little discussion, very little email followup, everyone dutifully using the microphones and jabber scribing, although there seemed to be only a single remote participant who actually participated (and that is one more than many RGs usually have.)
> 
> (To be clear: I picked DCLC above as an example; I've experienced the same with other groups.)
> 
> So, I'd like to try a somewhat radical experiment in the IRTF, and try and meet differently. In short: No more huge IETF rooms, no more microphone lines, a lot fewer presentations.
> 
> The longer version is this:
> 
> 
> (1) Rooms 
> 
> I'm trying to see if the secretariat can set up one meeting room for the IRTF that has a boardroom-style table at the front of the room, and a few classroom-style seating rows in the back. The idea is that active participants chose to sit at the boardroom table, while folks that are mostly there to listen sit in the rows. As chairs, you either select who you think your active participants are by some process you choose, or you trust your participants to self-regulate. Yes, this will require some planning by the chairs.
> 
> The boardroom-style table has a few omnidirectional microphones, so people around the table can speak freely without needing to form a line. (Chairs may still need to manage a virtual queue when the discussion gets heated.) There is the usual floor mike near the classroom-style seating rows, so everyone has a chance to chime in.
> 
> (Variant: If the boardroom+classroom setup cannot be done, a boardroom-only setup may be sufficient. In that case, the chairs will need to crowd control their meeting in some form.)
> 
> It's likely that not everyone showing up for an RG session will fit into the room, if the seating arrangement is changed in this way. To me, this is fine. IRTF RGs do not do standards, and while I like the groups to be as open as possible, that doesn't mean that we need to cater to 200 tourists in an RG session that do not usefully contribute to what the RG is trying to achieve. I'm happy to be the point man here to argue this to the community, so chairs don't have to.
> 
> 
> (2) Remote attendance
> 
> Nobody at the boardroom table will remember to say their name before they speak. That's OK, as long as they say it once. Regular participants who happen to be remote will usually recognize others by voice. Everyone else will have a bit of a hard time.
> 
> That's OK by me - I don't think we need to bend over backwards to make in-room interactions too difficult for the sake of remote participants, few of whom actually do actively participate in the meeting. I wish there was a way to make in-room and remote participation similarly effective, but I don't know of one. If I have to pick, I want to optimize for those folks who actually show up in the room.
> 
> (Yes, this is controversial, and I would not suggest this for an IETF WG.)
> 
> 
> (3) Meeting style
> 
> In general, there are too many presentations at RG meetings, and too little discussion. Your duty as chairs is not to simply do a call for presentations and then fill up the available meeting time with random presentation requests as they come in. You are chairs because you care about the topic of your RG and want to see certain outcomes happening. Use the meeting time you have towards that goal. Be ruthless.
> 
> This can mean no presentations at all. It can mean having a single, carefully prepared presentation on a hard question, followed by a long discussion. It can mean a series of related smaller presentations on a given topic, followed by discussion. Do whatever furthers the goals you want to achieve.
> 
> I've been in too many RG meetings that filled 80% of their agenda time with presentations, all of which ran long, leaving maybe 5% of the effective time for any sort of group discussion. If your group needs this kind of meeting at the moment , please consider if a Webex wouldn't be a more effective way of making progress. There is no need to wait for a face-to-face opportunity for these meetings, and wasting facetime on such meetings doesn't seem like a great idea.
> 
> (There are RGs that operate more like academic workshops, i.e., the NMRG at the moment. Much of the above doesn't really apply to them.)
> 
> 
> I'm very interested in your feedback here. I have chatted with the secretariat in London about whether the boardroom+classroom setup is possible to try out in Honolulu (and I'm CC'in Stephanie so she remembers we chatted about this, since it was Friday :-)
> 
> Once this is hashed out a bit more, I'd love for some RGs to try this approach out and see if it works better for them.
> 
> Lars
>

---

From: Weixinpeng <[email-masked]>
Date: Fri, 22 Aug 2014 09:59:04 +0000

Hi Fred and all,
Let me introduce something people we are working on in TSVWG that people here may be interested in.
What we are doing is about how to do congestion control in tunnel scenario, and aspects such as basic congestion control model, feedback mechanism are discussed.
I think the DC is a good scenario that the mechanism is suited to. So if you have interests on this, I prefer to have a discussion about it in DCLC. 
Here is the link for the document,
http://datatracker.ietf.org/doc/draft-wei-tsvwg-tunnel-congestion-feedback/ 
Thanks!

BR,
Xinpeng

>-----Original Message-----
>From: Dclc [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
>Sent: Tuesday, August 19, 2014 11:37 PM
>To: dclc
>Cc: 邓灵莉/Lingli Deng
>Subject: Re: [Dclc] Increasing RG meeting effectiveness
>
>I had a strange mail outage; I sent this a couple of days ago, and I see it
>neither in my own records nor on dclc@. Apologies if it’s a repeat.
>
>Lars (IRTF Chair) sent the following a couple of weeks ago. We’re a poster
>child, and Lingli and I think the point is well taken.
>
>We have had two meetings. One, at IETF-89, wasn’t widely announced. It
>happened in a small room with perhaps 20 chairs and as many people. Lingli
>showed a couple of slides, as did I, and we had a good general discussion. Our
>first “real” meeting was at IETF-90, in a room for 300 with construction noise
>and 39 scattered participants. A number of factors contributed, but the
>meeting was well described as a sequence of presentations with a little
>discussion after each.
>
>Lars is suggesting meetings in places suited to the number of participants, in a
>discussion format. Sounds good to us. If that makes someone feel excluded,
>we obviously don’t want that, but we think this might be more inclusive
>anyway.
>
>My suggestion for the moment is that people post what they like to the list,
>and if we have enough to have one, we can have a webex-or-whatever
>meeting. Otherwise, perhaps in October, we’ll ask what topics people would
>like to discuss f2f, and organize a meeting around a few topics.
>
>> I've been thinking about how we can increase the effectiveness of IRTF RG
>meetings during IETF weeks. My personal experience over the last few years is
>that RG meetings in very large IETF meeting rooms generally do not work well
>for many RGs.
>>
>> These huge IETF rooms encourage a one-way pass-down of information from
>the speaker to the (silent) audience, and only a few participants (usually the
>same ones) making their way to the microphones to ask a few questions. It's
>usually impossible to have any sort of deeper or longer discussion under these
>circumstances.
>>
>> I'm not saying that these classroom-style setups are wrong for all RGs - they
>may work well for some that operate more like academic workshops (e.g.,
>NMRG), but they strike me as the wrong forum for RGs that need to operate
>differently in order to make progress.
>>
>> As an example, I was struck by how much more effective the DCLC side
>meeting in London was, compared to the on-the-agenda meeting the
>proposed RG had in Toronto. In London, the meeting was in a boardroom-style
>arrangement with about 20 seats; in Toronto, it was in a huge IETF meeting
>room with a 300-seat classroom setup.
>>
>> Part of the reason was that in the small room in London, no microphones
>were used, and there were almost no presentations. It was a free-flowing
>discussion that was minuted and later continued by email. The Toronto
>meeting, in contrast, emulated an IETF WG meeting as many RGs are prone to
>do when meeting in IETF rooms: invited presentations, very little discussion,
>very little email followup, everyone dutifully using the microphones and
>jabber scribing, although there seemed to be only a single remote participant
>who actually participated (and that is one more than many RGs usually have.)
>>
>> So, I'd like to try a somewhat radical experiment in the IRTF, and try and
>meet differently. In short: No more huge IETF rooms, no more microphone
>lines, a lot fewer presentations.
>>
>> I'm trying to see if the secretariat can set up one meeting room for the IRTF
>that has a boardroom-style table at the front of the room, and a few
>classroom-style seating rows in the back. The idea is that active participants
>chose to sit at the boardroom table, while folks that are mostly there to listen
>sit in the rows. As chairs, you either select who you think your active
>participants are by some process you choose, or you trust your participants to
>self-regulate. Yes, this will require some planning by the chairs.
>>
>> The boardroom-style table has a few omnidirectional microphones, so
>people around the table can speak freely without needing to form a line.
>(Chairs may still need to manage a virtual queue when the discussion gets
>heated.) There is the usual floor mike near the classroom-style seating rows,
>so everyone has a chance to chime in.
>>
>> (Variant: If the boardroom+classroom setup cannot be done, a
>boardroom-only setup may be sufficient. In that case, the chairs will need to
>crowd control their meeting in some form.)
>>
>> It's likely that not everyone showing up for an RG session will fit into the
>room, if the seating arrangement is changed in this way. To me, this is fine.
>IRTF RGs do not do standards, and while I like the groups to be as open as
>possible, that doesn't mean that we need to cater to 200 tourists in an RG
>session that do not usefully contribute to what the RG is trying to achieve. I'm
>happy to be the point man here to argue this to the community, so chairs
>don't have to.
>>
>>
>> (2) Remote attendance
>>
>> Nobody at the boardroom table will remember to say their name before
>they speak. That's OK, as long as they say it once. Regular participants who
>happen to be remote will usually recognize others by voice. Everyone else will
>have a bit of a hard time.
>>
>> That's OK by me - I don't think we need to bend over backwards to make
>in-room interactions too difficult for the sake of remote participants, few of
>whom actually do actively participate in the meeting. I wish there was a way
>to make in-room and remote participation similarly effective, but I don't know
>of one. If I have to pick, I want to optimize for those folks who actually show
>up in the room.
>>
>> In general, there are too many presentations at RG meetings, and too little
>discussion. Your duty as chairs is not to simply do a call for presentations and
>then fill up the available meeting time with random presentation requests as
>they come in. You are chairs because you care about the topic of your RG and
>want to see certain outcomes happening. Use the meeting time you have
>towards that goal. Be ruthless.
>>
>> This can mean no presentations at all. It can mean having a single, carefully
>prepared presentation on a hard question, followed by a long discussion. It
>can mean a series of related smaller presentations on a given topic, followed
>by discussion. Do whatever furthers the goals you want to achieve.
>>
>> I've been in too many RG meetings that filled 80% of their agenda time with
>presentations, all of which ran long, leaving maybe 5% of the effective time for
>any sort of group discussion. If your group needs this kind of meeting at the
>moment , please consider if a Webex wouldn't be a more effective way of
>making progress. There is no need to wait for a face-to-face opportunity for
>these meetings, and wasting facetime on such meetings doesn't seem like a
>great idea.
>>
>> (There are RGs that operate more like academic workshops, i.e., the NMRG
>at the moment. Much of the above doesn't really apply to them.)
>>
>>
>> I'm very interested in your feedback here. I have chatted with the secretariat
>in London about whether the boardroom+classroom setup is possible to try
>out in Honolulu (and I'm CC'in Stephanie so she remembers we chatted about
>this, since it was Friday :-)
>>
>> Once this is hashed out a bit more, I'd love for some RGs to try this
>approach out and see if it works better for them.
>>
>> Lars
>>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 22 Aug 2014 17:10:04 +0000

> http://datatracker.ietf.org/doc/draft-wei-tsvwg-tunnel-congestion-feedback/ 

Thanks for the pointer. The questions that comes quickly to mind are:
1) does the proposed algorithm manage latency?
2) is it intended for use in a data center?

There are other places where latency is an issue; for example, RFCs 6057 and 6817 are in direct response to issues of latency and loss as a result of bitorrent use in residential broadband networks. At some point, it would likely be of value to widen our scope to look at such issues.

It is described as "congestion control", not "latency control". In terms of TCP's knee and cliff, I would expect congestion control would be about maximizing throughput while "not hitting the cliff" and latency control would be about maximizing throughput while "seeking the knee". Which goal does your algorithm trend towards? In other words, I’m not stating that it is, but I wonder: would ICCRG be a better venue?

How would you answer those questions?

> _______________________________________________
> Dclc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dclc

---

From: Weixinpeng <[email-masked]>
Date: Mon, 25 Aug 2014 07:17:02 +0000

Hi Fred,
Thanks for your questions, and here are my answers:
(1) The main point provided by the draft is a feedback mechanism for conveying congestion level from tunnel egress point to tunnel ingress, 
the mechanism is independent of specific traffic control algorithm, and we left traffic control function out of scope. So I think the mechanism could also be used for latency control.
(2) Because in DC scenario, tunnel is widely used, so we think DC is one of the usage scenario of the feedback mechanism, and we intend to include DC scenario in the coming version.

Thanks
-Xinpeng

>From: Fred Baker (fred) [mailto:[email-masked]]
>Sent: Saturday, August 23, 2014 1:10 AM
>To: Weixinpeng
>Cc: dclc; 邓灵莉/Lingli Deng
>> What we are doing is about how to do congestion control in tunnel scenario,
>and aspects such as basic congestion control model, feedback mechanism are
>discussed.
>> I think the DC is a good scenario that the mechanism is suited to. So if you
>have interests on this, I prefer to have a discussion about it in DCLC.
>There are other places where latency is an issue; for example, RFCs 6057 and
>6817 are in direct response to issues of latency and loss as a result of
>bitorrent use in residential broadband networks. At some point, it would likely
>be of value to widen our scope to look at such issues.
>
>It is described as "congestion control", not "latency control". In terms of TCP's
>knee and cliff, I would expect congestion control would be about maximizing
>throughput while "not hitting the cliff" and latency control would be about
>maximizing throughput while "seeking the knee". Which goal does your
>algorithm trend towards? In other words, I’m not stating that it is, but I
>wonder: would ICCRG be a better venue?
>
>>> I had a strange mail outage; I sent this a couple of days ago, and I
>>> see it neither in my own records nor on dclc@. Apologies if it’s a repeat.
>>>
>>> Lars (IRTF Chair) sent the following a couple of weeks ago. We’re a
>>> poster child, and Lingli and I think the point is well taken.
>>>
>>> We have had two meetings. One, at IETF-89, wasn’t widely announced.
>>> It happened in a small room with perhaps 20 chairs and as many
>>> people. Lingli showed a couple of slides, as did I, and we had a good
>>> general discussion. Our first “real” meeting was at IETF-90, in a
>>> room for 300 with construction noise and 39 scattered participants. A
>>> number of factors contributed, but the meeting was well described as
>>> a sequence of presentations with a little discussion after each.
>>>
>>> Lars is suggesting meetings in places suited to the number of
>>> participants, in a discussion format. Sounds good to us. If that
>>> makes someone feel excluded, we obviously don’t want that, but we
>>> think this might be more inclusive anyway.
>>>
>>> My suggestion for the moment is that people post what they like to
>>> the list, and if we have enough to have one, we can have a
>>> webex-or-whatever meeting. Otherwise, perhaps in October, we’ll ask
>>> what topics people would like to discuss f2f, and organize a meeting
>around a few topics.
>>>
>>> meetings during IETF weeks. My personal experience over the last few
>>> years is that RG meetings in very large IETF meeting rooms generally
>>> do not work well for many RGs.
>>>>
>>> the speaker to the (silent) audience, and only a few participants
>>> (usually the same ones) making their way to the microphones to ask a
>>> few questions. It's usually impossible to have any sort of deeper or
>>> longer discussion under these circumstances.
>>>>
>>> may work well for some that operate more like academic workshops
>>> (e.g., NMRG), but they strike me as the wrong forum for RGs that need
>>> to operate differently in order to make progress.
>>>>
>>> proposed RG had in Toronto. In London, the meeting was in a
>>> boardroom-style arrangement with about 20 seats; in Toronto, it was
>>> in a huge IETF meeting room with a 300-seat classroom setup.
>>>>
>>> were used, and there were almost no presentations. It was a
>>> free-flowing discussion that was minuted and later continued by
>>> email. The Toronto meeting, in contrast, emulated an IETF WG meeting
>>> as many RGs are prone to do when meeting in IETF rooms: invited
>>> presentations, very little discussion, very little email followup,
>>> everyone dutifully using the microphones and jabber scribing,
>>> although there seemed to be only a single remote participant who
>>> actually participated (and that is one more than many RGs usually
>>> have.)
>>>>
>>>> (To be clear: I picked DCLC above as an example; I've experienced
>>>> the same
>>> with other groups.)
>>>>
>>> meet differently. In short: No more huge IETF rooms, no more
>>> microphone lines, a lot fewer presentations.
>>>>
>>> classroom-style seating rows in the back. The idea is that active
>>> participants chose to sit at the boardroom table, while folks that
>>> are mostly there to listen sit in the rows. As chairs, you either
>>> select who you think your active participants are by some process you
>>> choose, or you trust your participants to self-regulate. Yes, this will require
>some planning by the chairs.
>>>>
>>> heated.) There is the usual floor mike near the classroom-style
>>> seating rows, so everyone has a chance to chime in.
>>>>
>>> boardroom-only setup may be sufficient. In that case, the chairs will
>>> need to crowd control their meeting in some form.)
>>>>
>>> IRTF RGs do not do standards, and while I like the groups to be as
>>> open as possible, that doesn't mean that we need to cater to 200
>>> tourists in an RG session that do not usefully contribute to what the
>>> RG is trying to achieve. I'm happy to be the point man here to argue
>>> this to the community, so chairs don't have to.
>>>>
>>>>
>>>> (2) Remote attendance
>>>>
>>> they speak. That's OK, as long as they say it once. Regular
>>> participants who happen to be remote will usually recognize others by
>>> voice. Everyone else will have a bit of a hard time.
>>>>
>>> in-room interactions too difficult for the sake of remote
>>> participants, few of whom actually do actively participate in the
>>> meeting. I wish there was a way to make in-room and remote
>>> participation similarly effective, but I don't know of one. If I have
>>> to pick, I want to optimize for those folks who actually show up in the
>room.
>>>>
>>> discussion. Your duty as chairs is not to simply do a call for
>>> presentations and then fill up the available meeting time with random
>>> presentation requests as they come in. You are chairs because you
>>> care about the topic of your RG and want to see certain outcomes
>>> happening. Use the meeting time you have towards that goal. Be ruthless.
>>>>
>>> prepared presentation on a hard question, followed by a long
>>> discussion. It can mean a series of related smaller presentations on
>>> a given topic, followed by discussion. Do whatever furthers the goals you
>want to achieve.
>>>>
>>> presentations, all of which ran long, leaving maybe 5% of the
>>> effective time for any sort of group discussion. If your group needs
>>> this kind of meeting at the moment , please consider if a Webex
>>> wouldn't be a more effective way of making progress. There is no need
>>> to wait for a face-to-face opportunity for these meetings, and
>>> wasting facetime on such meetings doesn't seem like a great idea.
>>>>
>>> in London about whether the boardroom+classroom setup is possible to
>>> try out in Honolulu (and I'm CC'in Stephanie so she remembers we
>>> chatted about this, since it was Friday :-)
>>>>