Re: [Dclc] Increasing RG meeting effectiveness

[Weixinpeng <[e-mail]>]

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

>-----Original Message-----
>From: Fred Baker (fred) [mailto:[e-mail]]
>Sent: Saturday, August 23, 2014 1:10 AM
>To: Weixinpeng
>Cc: dclc; 邓灵莉/Lingli Deng
>Subject: Re: [Dclc] Increasing RG meeting effectiveness
>
>
>On Aug 22, 2014, at 2:59 AM, Weixinpeng <[e-mail]> wrote:
>
>> 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-feed
>> back/
>> Thanks!
>
>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?
>
>> BR,
>> Xinpeng
>>
>>> -----Original Message-----
>>> From: Dclc [mailto:[e-mail]] 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.
>>>
>>> On Aug 11, 2014, at 11:55 PM, Eggert, Lars <[e-mail]> 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
>>>>
>>
>> _______________________________________________
>> Dclc mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/dclc