[00:35:33] Qin W leaves the room
[06:21:06] Andrew McGregor joins the room
[09:07:09] Qin W joins the room
[09:08:04] Qin W leaves the room
[09:11:42] moeller0@jabber.uk joins the room
[09:56:38] Qin W joins the room
[09:59:16] Qin W leaves the room
[10:02:40] Qin W joins the room
[10:04:01] Qin W leaves the room
[11:41:18] moeller0@jabber.uk leaves the room
[11:41:19] moeller0@jabber.uk joins the room
[11:46:13] moeller0@jabber.uk leaves the room
[11:46:13] moeller0@jabber.uk joins the room
[11:51:51] moeller0@jabber.uk leaves the room
[11:55:06] moeller0@jabber.uk joins the room
[11:55:23] <moeller0@jabber.uk> Does this work?
[12:09:06] moeller0@jabber.uk leaves the room
[12:09:12] moeller0@jabber.uk joins the room
[12:10:42] moeller0@jabber.uk leaves the room
[12:18:01] moeller0@jabber.uk joins the room
[12:20:46] moeller0@jabber.uk leaves the room
[12:20:46] moeller0@jabber.uk joins the room
[13:50:25] <Andrew McGregor> Yes, there's just the two of us here right now.
[13:53:54] Magnus Westerlund joins the room
[13:55:46] <Magnus Westerlund> So the Webex meeting is open now, welcome in.
[13:57:24] <moeller0@jabber.uk> okay, any need to register somewhere?
[13:58:46] <Magnus Westerlund> There will be a blue sheet name collection.
[13:59:07] <moeller0@jabber.uk> Thanks, found it.
[13:59:08] martin.duke joins the room
[13:59:45] Jake joins the room
[13:59:59] <Magnus Westerlund> Blue sheet: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03?useMonospaceFont=true
[14:00:15] slblake joins the room
[14:01:06] <Andrew McGregor> Blue sheet: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03?useMonospaceFont=true
[14:02:29] Alissa Cooper joins the room
[14:04:01] Mirja joins the room
[14:04:15] kiran.ietf joins the room
[14:04:25] csperkins joins the room
[14:04:37] gorryf joins the room
[14:05:22] <Magnus Westerlund> So the correct the Webex link is: https://ietf.webex.com/ietf/j.php?MTID=m85a008baf8423b11e0c587804eed7a34
[14:06:02] <slblake> I sent out a Webex link last night from an invitation that was sent out for today's interim 3 weeks ago. My bad. See the email Gorry sent out this morning for the correct Webex link.
[14:06:05] spencerdawkins joins the room
[14:07:38] dragana joins the room
[14:08:20] nygren joins the room
[14:08:41] Qin W joins the room
[14:09:43] chi.jiun.su joins the room
[14:10:04] <Magnus Westerlund> So I would expect that people will normally be able to comment in the Webex meeting. However, if you really need something relayed please prefix it with Mic:
[14:10:22] <spencerdawkins> There is no advantage to being a TSVWG co-chair :-)
[14:10:33] roland.bless joins the room
[14:11:25] bob.briscoe joins the room
[14:11:42] Qin W leaves the room
[14:13:13] <slblake> I have joined the wrong Webex and directed everyone there to the correct one.
[14:14:23] <spencerdawkins> @slblake - thank you for that!
[14:14:50] Qin W joins the room
[14:16:29] mallman joins the room
[14:17:38] Qin W leaves the room
[14:19:31] tomhenderson joins the room
[14:20:03] <gorryf> Wes is describing the meeting slide deck....
[14:24:05] <spencerdawkins> Input vs output was a terrific insight,
[14:25:15] michael.welzl joins the room
[14:30:52] nygren joins the room
[14:30:54] lpardue joins the room
[14:31:02] <Jake> i'm trying to hold my breath and not confuse anyone, but since a few days ago i've started to think that although input/output looked like a very good clarifying question and made a very good forcing function to think it through, it might have been the wrong question.
[14:31:50] <slblake> Correct me if I am wrong, but my understanding is that the tsvwg milestones for L4S are for experimental RFC, not standards track. Is this correct?
[14:32:01] cheshire@jabber.org joins the room
[14:32:08] <Jake> the real question to me by today is whether redefinition of ce as approached by L4S has met the rfc8311 requirements, and i would argue the problem is it has not.
[14:32:22] <gorryf> TH
[14:33:16] <Jake> @steven, that's my understanding, yes.
[14:33:37] <Mirja> What do you mean by redefinition of CE?
[14:33:42] <Magnus Westerlund> Steven Blake: Yes, the milestones are for informational architecture and experimental component specifications.
[14:34:37] <gorryf> Info: The RFC8311 change was done specifically by TSVWG to enable the ABE work to be started and to enable adoption of the L4S work - both as EXP ...
[14:34:44] <Jake> L4S says it's not equivalent to loss and requiring a MD in response to CE from network.
[14:34:59] <Jake> 8311 allows this, but sets a high bar on its requirements
[14:36:27] <Mirja> it's this more relevant for ABE (RFC8511)
[14:37:57] mallman leaves the room
[14:39:51] <spencerdawkins> Well, stripping off ECT(1) markings is "special" ... =-O
[14:41:01] <Jake> sure, but CE as a backstop that ensures safety is a useful property.  removing it is kind of dangerous and not such a good idea if you want to do it in a flaky way.  that's the main thrust of my position statement, i think.
[14:41:39] <spencerdawkins> @Jake - understood.
[14:41:54] <Jake> plus some commentary about reasonable solutions that it's not clear how solid it is in light of the tunneling comments and depends on the deployment context probably, but that's a different can of worms i guess.
[14:42:49] <gorryf> So the basis of ABE was that the backstop signal: loss - the only “reliable” congestion signal is lack of ACK. CE is an incipient signal, that helps avoid that loss signal.
[14:43:26] <Mirja> I don't think the backstop is removed at all as long as CE is used as some congestion input (however I think there are already system which set ECT to get a benefit but then might ignore CE because they e.g. don't even have an appropriate feedback channel). Loss might here be the real backstop
[14:43:49] <spencerdawkins> @Jake - I could be senile, but ISTM that we worked for a long time on L4S without talking about tunneling very much. Maybe everyone thought that was obvious, but I didn't realize that if it was happening.
[14:45:44] <Jake> @mirja that's interesting, would be interested to see the traces on that.
[14:47:47] <Mirja> unreliable media with UDP at the lowest layer was considering that. Not sure what's deployed…
[14:49:43] Qin W joins the room
[14:49:59] Qin W leaves the room
[14:50:23] <gorryf> :Jake ... At the same time, TSVWG did prioritise ECN updates for (a long list of) IETF tunnel specs ...
[14:51:15] Qin W joins the room
[14:54:12] <bob.briscoe> I had asked the chairs to ask Jonathan to remove the last paragraph of his "Plans to Deploy" slide about what companies supporting L4S could be expected to do, which the L4S proponents strongly disagree with. The L4S proponents refused.
[14:54:43] <spencerdawkins> Does anyone know how recently 3GPP has planned to include L4S? I know we were talking with them like three years ago, but I'm not current.
[14:58:02] Luca Muscariello joins the room
[14:58:43] <bob.briscoe> Is Dave Taht on this chat under some name?
[14:58:46] <Magnus Westerlund> From Per Willars (Ericsson colleague) in answer to Spencer question: L4S can be deployed over 3GPP networks as of today. What was postponed was an optimization for one of the internal interfaces in the base station. MOre important: ECT(1) as input fits very well with the 3gpp bearer model.
[14:59:07] <slblake> Rude Goldberg == Dave Taht
[15:00:02] <moeller0@jabber.uk> Sweet, so all I need to do is mark ECT(1) to get on a low latency bearer?
[15:01:00] <Mirja> low latency potentially yes but not more throughput
[15:01:01] <slblake> LOL. Rube Goldberg == Dave Taht, not Rude. No offense Dave.
[15:01:02] <bob.briscoe> Recent testing: http://folk.uio.no/asadsa/ecn-fbk/results_v2.2/ with short web-like flows. Not asymmetric, but we can add that (and should, 'cos we've claimed the L4S survives ACK thinning much better than SCE). Also short flows in v extensive tests 5 years ago.
[15:01:51] <bob.briscoe> @sblake, yes but I don't see Glodberg on /here/.
[15:02:37] Qin W leaves the room
[15:02:39] Qin W joins the room
[15:02:49] <spencerdawkins> Webex chat actually goes away at the end of the call ;-)
[15:04:05] Qin W leaves the room
[15:05:21] Qin W joins the room
[15:05:32] <moeller0@jabber.uk> But trusting classification without monitoring and policing of expected behaviour, really leads to abuse problems.
[15:07:01] <Magnus Westerlund> @Moeller0 if your L4S traffic gets the same amount of resources as non-L4S then that is not an issue.
[15:07:02] <Mirja> L4S is not a priority scheme, it rather gives you a completely different traffic handling. If you use classic congestion control with ECT(1) you will probably not get great performance
[15:08:02] <moeller0@jabber.uk> The thing is, L4S does not aim to equitably share resources
[15:08:39] <moeller0@jabber.uk> The L4S queue gets reliably more throughput than the classic queue
[15:09:21] xdf joins the room
[15:09:31] <Mirja> then upgrade to L4S ;-)
[15:09:44] cabo joins the room
[15:09:53] <moeller0@jabber.uk> No, better, just mark ECT(1) and ignore CE...
[15:10:14] <Mirja> you can do that today with any ECN scheme
[15:10:45] Luca Muscariello leaves the room
[15:10:51] <moeller0@jabber.uk> But these do not give me reliably more thoughput, as L4S as currently implemented does, but I digress, this is about ECT(1).
[15:10:54] Luca Muscariello joins the room
[15:11:03] <Jake> i'd be fine with l4s if it didn't break regular ecn queues.  would love to see ce stay the same and use ect(1)->ect(0) as low-congestion signal, and fix up the rest of the specs around that.
[15:11:10] <Jake> with a md response to any seen ce.
[15:11:41] <Jake> this avoids breaking existing aqms and makes a good path forward
[15:12:11] <Jake> just doesn't start off with the perfect ll is the only problem with it.
[15:12:24] <Magnus Westerlund> @moeller0 however in a mobile network there are an underlying bearers that will perform resource sharing between the bearers.
[15:13:01] <Magnus Westerlund> To my understanding DOCSIS has a mechanism that demotes misbehaving L4S flows to he classic queue
[15:13:16] <roland.bless> I also don't want to see this discussion as SCE vs. L4S, so I'd like to use ECT(1) as signal and an additional DSCP for classification for L4S
[15:14:02] <slblake> @roland.bless: exactly. I don't know why this conversation always devolves into a debate between the two.
[15:14:10] <spencerdawkins> @roland, yes, and I don't think that got enough discussion early on in this comparison (or even in L4S discussion).
[15:15:15] <spencerdawkins> "that" being "use of DSCP as part of the discussion" - sorry for being vague.
[15:16:45] <slblake> I support the Diffserv architecture (surprised?). DSCP steers packets into queues. The ultimate end-game is that all transports evolve to 1/p response with support for high-fidelity ECN signaling in the network, and we don't need dual queues for every PHB.
[15:26:34] <nygren> (Reminder to keep conversations here, not in the WebEx.)
[15:26:59] <spencerdawkins> Is Etherpad still working for others? I was force disconnected and now "etherpad.ietf.org didn't send any data" when I reload.
[15:27:37] <slblake> I can edit (see my name)
[15:28:22] <spencerdawkins> I was in mid-correction when I was disconnected. Not sure what my problem is.
[15:29:08] chi.jiun.su leaves the room
[15:29:16] chi.jiun.su joins the room
[15:30:08] <gorryf> I don’t know that ether pad is working
[15:30:35] <slblake> I got kicked off my I am back on and can edit (see my name)
[15:34:36] <Alissa Cooper> I sent in a ticket re the etherpad — seems like not the usual etherpad connectivity problem
[15:35:15] <Andrew McGregor> If we had peering agreements for dscp end-to-end, that would make sense. We mostly don't. We have bleaching nearly everywhere.
[15:35:17] <spencerdawkins> @Alissa, thank you.
[15:35:46] <spencerdawkins> @Andrew - that's not a feature :-(
[15:35:52] <slblake> See draft-blake-explu-dscp-rec
[15:37:17] <nygren> Some of the places where you get the most value out of this for ultra-low-latency are places with clients and servers nearby in network topology and geographically, and those may be the places where getting dscp working end-to-end is more viable.
[15:37:53] <Andrew McGregor> Fully support trying to get dscp sorted. But we have an option to not tie the two things together, by accident of history.
[15:38:12] <Mirja> +1 Andrew
[15:38:17] <slblake> RFC2474 correctly recommended how to handle unused DSCPs (don't bleach) and RFC2475 muddied the issue and I'm the idiot who edited both. Listen to 2474.
[15:39:02] <spencerdawkins> @slblake, I HATE it when I do that ;-)
[15:39:04] <Mirja> let's not make failing/success of one experiment dependent on the failing/success of another experiment
[15:39:44] <slblake> Are you proposing dual-Q for every deployed PHB?
[15:40:07] <Andrew McGregor> If l4s is where we go, it might make the point that end-to-end dscp is worth having
[15:40:27] <gorryf> +1
[15:40:36] <slblake> @andrew: yes.
[15:41:02] <Andrew McGregor> Dual-Q for every PHB… well, you could, but I don't think it's totally necessary
[15:41:26] <slblake> I don't know why the word "deploy" is being used. We are talking about an experiment. IMHO dual-Q will not survive contact with the Internet as is. That's fine. Let's experiment and learn.
[15:42:41] <slblake> @andrew: if you use ECT-1 as input and don't have dual-Q for every PHB then you have two conflicting inputs trying to steer packets. How do you sort that out?
[15:42:57] <spencerdawkins> @slblake - the concern as I understand it is that if an ECT(1) mechanisms escapes into the Internet, it will be a couple of decades before we can confidently reuse it. I would love to be wrong about that.
[15:43:13] <nygren> Is this realistically an experiment?  If CableLabs and 3GPP are trying to take this seriously and deploy on a widespread basis in consumer hardware, that seems much more than an experiment.
[15:43:33] <slblake> @spencer: that is why I don't think we should lock that in until there is a lot more real-network experimental data.
[15:43:34] <nygren> (ie, are we being honest in thinking of this as "Experimental"?)
[15:43:54] <Mirja> for me the experiment is success when it gets widely deployed
[15:43:56] <spencerdawkins> @nygren - exactly. No, we're probably not, at this point.
[15:44:01] <gorryf> Actually I think it is a deployment experiment - a standard we expect to confirm after doing experiments about the deployment issues.
[15:44:53] <slblake> IMHO neither L4S or SCE are mature enough to consider deployment. The impact either may have on competing traffic is really unknown.
[15:44:54] <Andrew McGregor> Some PHBs don't make much sense for TCP as it is, so running dual-q in those seems unnecessary. But dual-q for anything that is expected to have TCP in any volume seems sensible.
[15:45:03] <spencerdawkins> The related question is whether we could ever deploy another ECT(1) mechanism if we deploy one now.
[15:45:12] <moeller0@jabber.uk> @Gory, as far as I can tell we are still discussiong whether L4S actually dekivers what it promises?
[15:46:11] <moeller0@jabber.uk> Duration of development effort is not a strict predictor for quality of the resulting implementation.
[15:47:36] <gorryf> To me: The key question is what is driving the architecture, and who wants that architecture -  and what *CAN* we tune the details as a WG as this experiment progresses?
[15:48:57] <slblake> Any of the big operators on the L4S supporters list could "deploy" L4S internally using either DSCP (or ECT(1) if internal-only) for a while across a huge network and we could see some data.
[15:52:13] Glen (AMS IT) joins the room
[15:52:54] Qin W leaves the room
[15:55:37] krose joins the room
[15:57:11] <slblake> From Dave Taht to last speaker from Mellanox: How many hardware queues do they present to the OS? 64 or more, last I checked.
[15:57:37] <gorryf> The endpoint stack need to deploy the new CC ... and then do you mean bleach the codepoint for traffic that leaves their own network?
[15:57:43] Glen (AMS IT) leaves the room
[15:59:24] Luca Muscariello leaves the room
[15:59:30] Luca Muscariello joins the room
[15:59:36] <Magnus Westerlund> On Bob's comments regarding the saftey of deploying remarking of ECT(0) to ECT(1) I am co-author of one specification that actually will detect this remarking as it does full feedback of all received ECN code points for a flow to the sender. That is ECN for RTP over UDP (https://datatracker.ietf.org/doc/rfc6679/). Section 7.4 discuss this. The response to this case is likely implementation dependent.
[15:59:40] <martin.duke> @slblake. Deploying L4S with a DSCP solves the traffic in one direction. Assuming bleaching elsewhere in the network, the operator would have to somehow detect L4S traffic and re-mark it correctly
[16:00:36] <gorryf> That sounds quite weird.
[16:00:41] <Alissa Cooper> Anyone still having etherpad problems?
[16:01:45] <bob.briscoe> @Magnus AccECN (used By L4S for TCP feedback) checks for the network changing ECT(0) and ECT(1) during handshake.
[16:02:30] <bob.briscoe> To be precise, it chaks for any invalid ECN transition.
[16:03:30] <Magnus Westerlund> @bob the point I think is that there are at least a couple of IETF specifications that will be able to determine this remarking. I think the response to this is more uncertain.
[16:04:07] Glen (AMS IT) joins the room
[16:04:31] <krose> From my perspective, the ambiguity in CE is the real problem. If classic ECN were explicitly deprecated as part of the L4S work, and effort made to actually remove it from endpoints and existing deployed AQMs prior to widespread L4S deployment, a lot of my objections would be mooted. That said, doing so would be an enormous effort.
[16:04:45] <slblake> Let's say operators agree to deploy a new low-latency service on the internet for traffic using a new CC algorithm, and are willing to offer it to all comers without service level agreements or extra $$. Then they need to agree on a classification key for such traffic, and agree to pass it transparently e2e. Every piece of HW deployed in the last 15+ years supports DSCP for this function, and supports the configuration to map to it PHBs and not bleach it. How much HW supports ECT(1) as a classfiication key?
[16:05:36] <spencerdawkins> I'm +1 on Lars and making a decision now.
[16:05:45] Glen (AMS IT) leaves the room
[16:06:24] <Mirja> @krose I guess we could deprecate it but it would just be words on paper… I don't think it make any difference in the real world
[16:06:45] nealcardwell joins the room
[16:06:56] <slblake> From Dave Taht: any cmts makers in the room? Downlink bloat is a big problem on cable, kept hoping for pie, at least, or sfqRube Goldberg12:04alistar, care to +q? I'd like a decision affter more asymmetric testing.
[16:07:24] <Andrew McGregor> WiFi is mostly implementation quality issues anyway, once you're past .11b
[16:07:25] <bob.briscoe> @glen, don't need to take Classic ECN off the table. See thread in response to Jake Holland's "Position Statement on ECT(1)". RFC3168 queues can just mark ECT(0) and apply AQM dropping to ECT(1), which gives L4S sender an explicit signal.
[16:07:34] <krose> Not sure I agree. Explicit deprecation means it will be removed from the most widely deployed ECN-marking AQM: fq_codel (and cake)
[16:07:39] <moeller0@jabber.uk> @Stuart that is demonstrably not the case
[16:08:03] <gorryf> So... I’m interested in whether there is anything we have learned since we started this in 2016, that would make us think that we need to pause on this?
[16:08:40] <spencerdawkins> @gorryf, that would be a spectacular question for the mike ...
[16:08:42] <nygren> That might argue even more-so for L4S being a proposed-standard rather than experimental (if it is going to deprecate classic ECN).
[16:09:34] <nygren> (Time check: there are 20 minutes left)
[16:10:03] <Mirja> @krose I'm pessimistic that writing it in an RFC will actually make any implementation change. But I agree with nygren that this should be don't when L4S is successfully deployed and right now
[16:10:17] <slblake> I agree with Stuart that if you are expecting the Internet to deploy a new service without $$ then there must be a trade-off, latency vs. thruput. Has this been demonstrated?
[16:10:24] <krose> You could still separate the two efforts, justifying deprecation on the relatively modest degree of deployment and use and on the need to free up those bits for experiments
[16:10:45] <martin.duke> This discussion has brought in a lot of voices beyond the proponents, which is great. But how do we move forward from here?
[16:11:11] <slblake> From Dave Taht: yes, stuart, your videoconference has to drop packets. on your 300 kbit lik=nk
[16:11:16] <krose> @mirja, can you rephrase/repeat? I don't understand your last sentence
[16:11:26] <bob.briscoe> @Luca. Regarding safety in core or peering links etc: see our Appx D of Classic AQM Fallback Algorithm paper  https://arxiv.org/pdf/1911.00710.pdf#appendix.D
[16:11:44] <csperkins> Video traffic is clearly elastic *within bounds*. We have an entire working group looking at video congestion control.
[16:11:59] Luca Muscariello leaves the room
[16:12:00] <Mirja> @krose was just agree that an experimental RFC should not deprecate RFC3168 ECN
[16:12:08] <krose> Agreed
[16:12:24] <spencerdawkins> @Martin, I think the first question is whether we move now or cxontinue to investigate.
[16:12:36] <Andrew McGregor> Think of WiFi (and other slow links) as being "speed of light" kind of issues… they're physical reality, while they exist.
[16:12:44] <krose> But I see no need to make L4S proposed standard in order to make ECN historic.
[16:13:12] <martin.duke> @spencerdawkins do you read the rough consensus as pursue L4S with some additional testing to resolve remaining concerns?
[16:13:22] <slblake> From Dave Taht: and compensate. l4s doesn't drop packets. (except under loads that have driven it to the drop point, and all applications suffeing). ping -f -Q 2 (or 1) somewhere on any single or dual queue desin.
[16:13:37] <krose> I wouldn't object to PS, FTR
[16:13:38] <Mirja> I would rather like to RFC3168 ECN to historic when we know we really don't need it anymore
[16:13:52] <spencerdawkins> @Martin.duke - I couldn't possibly comment, but perhaps the chairs could :-)
[16:14:25] <martin.duke> doesn't 3168 have the same incentives to cheat?
[16:15:05] <slblake> 3168 cheating leads to higher thruput at the expense of increased queueing latency.
[16:15:44] <bob.briscoe> The L4S queue doesn't /give/ you low latency. Your CC's behaviour causes the low latency. If it doesn't respond correctly, you don't 'get' low latency.
[16:16:17] <slblake> You get scheduling priority over classic queue.
[16:17:02] <Andrew McGregor> You might find yourself shallow buffered though
[16:17:07] <moeller0@jabber.uk> Worst case L4S : classic 15:1
[16:18:07] lpardue leaves the room: Disconnected: BOSH client silent for over 60 seconds
[16:18:12] dragana leaves the room: Disconnected: closed
[16:19:57] <moeller0@jabber.uk> If all other users of that shallow buffer nicely yield, that shallow buffer for myself might be all I need/want...
[16:22:04] <slblake> From Dave Taht: marvelous opportunity to see what happens with cheating. https://mailarchive.ietf.org/arch/msg/tsvwg/-vA09q9O0GYUZwa84GareleqgfM/
[16:23:47] <Mirja> from Olivier Tilmans as reply: Cheating only gets you so far: a) if you are responding to the ECN signal, and mismark yourself into the L queue, you starve yourself due to the order of magnitude higher amount of marks b) if you do not respond to signals, then you are unelastic and just decrease the amount of BW that is shared by responsive flows. The queue in which you sit for b) does not matter as the marking probabilities of both queues are coupled.  This point was confirmed both by the shared paper in July'19 (see overload experiments) and during the sce-bakeof test back in november'19
[16:24:51] <slblake> From Dave Taht: you aren't fighting off ddos attacks every day.
[16:25:27] lpardue joins the room
[16:25:43] <spencerdawkins> This is not a good topic to pioneer volume judgement in Webex by TSVWG chairs :-)
[16:25:53] <roland.bless> Decisions must be taken to the list anyway
[16:26:11] <cabo> Validated.  Not taken.
[16:27:05] <slblake> From Dave Taht: whenever we get to the final wrapup for a "hum" if we do
[16:28:24] <cabo> We should move to BigBlueButton then, that has instant polls…
[16:28:42] <cabo> With questions that need to be formulated before they can be answered...
[16:29:02] <spencerdawkins> I am impressed with how well this meeting has gone. Good job to everyone who behaved :-)
[16:29:13] <martin.duke> +1 to spencer
[16:30:23] kiran.ietf leaves the room
[16:31:20] <nygren> I wonder if "should [whatever] be experimental or proposed-standard" would be a good question for when we do polls
[16:31:47] nygren leaves the room: Disconnected: closed
[16:31:55] cheshire@jabber.org leaves the room
[16:31:55] michael.welzl leaves the room
[16:31:56] krose leaves the room
[16:33:05] moeller0@jabber.uk leaves the room
[16:33:35] bob.briscoe leaves the room
[16:33:54] slblake leaves the room
[16:34:40] Magnus Westerlund leaves the room
[16:37:09] Mirja leaves the room
[16:37:09] nygren joins the room
[16:37:21] nygren leaves the room
[16:37:37] nealcardwell leaves the room: Disconnected: BOSH client silent for over 60 seconds
[16:46:21] chi.jiun.su leaves the room
[16:53:07] martin.duke leaves the room
[16:56:25] nygren joins the room
[16:56:34] kiran.ietf joins the room
[17:02:09] nealcardwell joins the room
[17:18:35] lpardue leaves the room: Disconnected: BOSH client silent for over 60 seconds
[17:20:51] lpardue joins the room
[17:27:01] tomhenderson leaves the room
[17:35:03] nealcardwell leaves the room: Disconnected: BOSH client silent for over 60 seconds
[17:42:39] xdf leaves the room
[18:00:39] nygren leaves the room: Disconnected: closed
[18:18:51] lpardue leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:21:10] lpardue joins the room
[18:26:12] nygren joins the room
[18:55:30] kiran.ietf leaves the room
[19:14:29] gorryf leaves the room
[19:14:37] cabo leaves the room
[19:18:25] cabo joins the room
[19:18:37] cabo leaves the room
[19:38:38] cabo joins the room
[19:56:20] chi.jiun.su joins the room
[19:56:46] chi.jiun.su leaves the room
[20:17:30] lpardue leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:19:41] lpardue joins the room
[20:52:38] cabo leaves the room
[21:00:55] nygren leaves the room
[22:18:08] lpardue leaves the room: Disconnected: BOSH client silent for over 60 seconds
[22:19:51] lpardue joins the room
[22:56:15] roland.bless leaves the room
[23:12:23] lpardue leaves the room: Disconnected: BOSH client silent for over 60 seconds
[23:14:13] lpardue joins the room