IETF
QUIC
quic@jabber.ietf.org
Wednesday, September 19, 2018< ^ >
janaiyengar has set the subject to: Really Draining
Room Configuration
Room Occupants

GMT+0
[13:29:59] mnot joins the room
[13:30:06] <mnot> Hello.
[13:30:54] Lars Eggert joins the room
[13:31:20] spencerdawkins joins the room
[13:31:24] Christian joins the room
[13:31:34] Martin Thomson joins the room
[13:31:34] afrind joins the room
[13:31:49] <spencerdawkins> Hello, Mark.
[13:32:17] Eric Kinnear joins the room
[13:32:39] brian@trammell.ch joins the room
[13:32:43] Sean Turner joins the room
[13:33:11] chi.jiun.su joins the room
[13:34:02] lucaspardue joins the room
[13:34:13] ekr joins the room
[13:34:16] <ekr> https://docs.google.com/document/d/1qdZu4mksN8yOoIZPUKXC5GyzuDyEt3DWgjx-ZZOm8gM/edit
[13:34:20] masaori@xmpp.jp joins the room
[13:37:10] Mirja Kuehlewind joins the room
[13:37:35] Igor Lubashev joins the room
[13:37:54] subodh joins the room
[13:42:32] Jari Arkko joins the room
[13:58:54] <mnot> Remote folks: We’ve moved the mic a bit closer to the centre of the room. Please tell us if it’s better (or worse)
[14:01:30] <lucaspardue> christian is clear and audible
[14:01:38] <mnot> He’s close
[14:01:39] <mnot> :)
[14:01:47] <mnot> Tell us if there’s noise; the mic is right next to Lars
[14:03:06] <chi.jiun.su> still lower voice than previous meeting.
[14:03:16] <chi.jiun.su> Need to raise the speaker to the highest level
[14:05:07] hardie joins the room
[14:06:05] <mnot> Working on it
[14:06:36] <chi.jiun.su> now louder
[14:06:39] <mnot> How’s that?
[14:06:41] <Jari Arkko> audio level increased now
[14:06:42] <hardie> Louder
[14:06:53] <mnot> Ted: is that a comment or a request
[14:06:54] <spencerdawkins> Could I get in Q?
[14:07:00] <mnot> Spencer q+
[14:07:07] <Jari Arkko> (i've been hearing ok all the time.)
[14:08:06] <hardie> Someone's browser is showing the Mozilla encrypted DNS request modal dialog.  Can the room vote on the answer?
[14:08:20] <hardie> (Sorry, just found it funny)
[14:08:22] Sean Turner leaves the room
[14:08:58] <mnot> I note it’s an opt out. Tsk, tsk.
[14:09:57] <hardie> q to Jana: attack on what?
[14:11:03] <subodh> if people are giving preferential treatment based on rtts from spin bits, then you can just spin slower to inflate your rtt :)
[14:12:16] <hardie> @subodh  I'm having trouble seeing that working on any useful timescale, but I may be misunderstanding what you mean by preferential treatment
[14:12:28] <Martin Thomson> how are we doing on time here?
[14:12:35] <Martin Thomson> this seems to be headed for a rathole
[14:13:09] <hardie> @subodh  The proposal, unless it has changed, was that you could always refrain from sending this, so you have a bound on behavior in one direction.
[14:13:29] <Jari Arkko> current speaker is faint
[14:13:59] <chi.jiun.su> yes.
[14:16:49] <subodh> @hardie, for clarification, i'm not arguing either way right now.However in a "hypothetical" future in which someone decides to build a network optimizer based on a spin bit. Someone might decide that flows with higher rtts should be given better treatment than flows with lower rtt, for fairness. In this world an evil app can spin slower to inflate its rtt
[14:17:24] <Jari Arkko> someone typing loudly
[14:17:27] <subodh> again totally hypotheical, just an observation, and not arguing for anything :)
[14:17:57] <spencerdawkins> I thought that was someone drumming .. all thud, no clicks.
[14:19:15] <hardie> @subodh  What do you mean by "better treatment", for the mid-point device (which is where this might occur, since the sides have better data)?  Move to a higher priority router queue?  Change paths?  
[14:20:10] <subodh> by better treatment, i mean drop less packets. it might make sense to drop less packets on a high rtt path vs a low rtt path because low rtt can recover quicker in case of congestion
[14:20:28] <subodh> some sort of queue management
[14:20:54] <mnot> Spencer: new MacBook keyboard :-/
[14:26:08] <hardie> @subodh, okay, "different router queue".  We certainly have seen QoS marks ignored or bleached in the past because of this concern.  One of the interesting things about a protected set of spin bits is that you can pass the data through a network that has no interest in trusting the markings and still see it in networks that do.  That's a useful upgrade, because the current common approach (bleaching) is needed so that someone else's marks aren't conflated with your own markings.
[14:26:23] <Lars Eggert> yeah, sorry. i hate the new keyboard. maybe i sit elsewhere
[14:43:24] <spencerdawkins> @Lars, I'm the last person in this meeting to care about drumming in the background ;-)
[14:45:18] <spencerdawkins> Am I understanding that the worse the path gets, the better the measurements work because you have more samples? So the cases where this doesn't work well are where you're getting no reordering or loss, in which case, maybe you don't care?
[14:45:27] <Jari Arkko> no worries. just providing audio feedback to enable improvements :-)
[14:46:31] dkg joins the room
[14:46:58] Christian leaves the room: Disconnected: Replaced by new connection
[14:46:59] Christian joins the room
[14:47:22] <spencerdawkins> Is audio working well for remote attendees now?
[14:47:52] <chi.jiun.su> yes.
[14:48:33] <spencerdawkins> Thanks. I just went through a long period of garbled audio, but is cleaared up now.
[14:51:00] spencerdawkins joins the room
[14:51:37] <mnot> We’ve opened the windows a little bit to get some fresh air. Please say if the noise is distracting.
[14:51:57] <Jari Arkko> audio has worked quite well all the time, with some adjustments of mic locations over there. and a couple of instances of people speaking over each other but that's not a transport problem :-)
[14:53:46] <mnot> Next break we’re going to try putting the mic on a dedicated table, to isolate it from Lars and I a bit :)
[14:55:08] <spencerdawkins> I switched network paths (my stepdaughter and her wife live next door, and have a different ISP - we trade SSID passwords). Problem was definitely at my end.
[14:58:21] <spencerdawkins> +q?
[15:06:30] spencerdawkins leaves the room: Disconnected: No route to host
[15:07:05] spencerdawkins joins the room
[15:12:53] g.e.montenegro joins the room
[15:13:06] Sean Turner joins the room
[15:13:23] masaori@xmpp.jp leaves the room: Stream closed by us: Replaced by new connection (conflict)
[15:13:33] masaori@xmpp.jp joins the room
[15:13:51] <Christian> PCAP is network porn...
[15:14:14] <lucaspardue> +1 to standardising QUIC exchanges
[15:15:27] janaiyengar joins the room
[15:20:22] spencerdawkins joins the room
[15:22:10] spencerdawkins leaves the room: Disconnected: closed
[15:23:10] <hardie> q+
[15:24:47] Christian leaves the room: Disconnected: Replaced by new connection
[15:24:48] Christian joins the room
[15:25:02] spencerdawkins joins the room
[15:28:03] spencerdawkins leaves the room: Disconnected: timeout during writing
[15:28:56] <hardie> Convince the working group presumes the answer; enable the working group to make the decision is a more neutral formulation.
[15:29:31] <Mirja Kuehlewind> a comment on this loss/reordering estimate: this is basically estimating the loss/reordering rate based on a one sample per RTT sample rate, so if you measure long enough (if you have a long enough flow), you will measure the actually rate
[15:29:41] <spencerdawkins> Just to clarify - the spin bit is not gating for what we're calling version 1, is that right?
[15:29:52] <spencerdawkins> I think Lars said that but want to make sure.
[15:30:57] <Lars Eggert> right. we said that we're trying to conclude the discussion on the spin bit before we ship v1, but we're not holding up v1 if it hasn't concluded. (we can always add things to quic later)
[15:33:01] <spencerdawkins> Lars, that was my understanding - just making sure I'm still in sync. Thanks for confirming.
[15:34:34] <spencerdawkins> +q?
[15:34:58] <Mirja Kuehlewind> +q
[15:35:21] <spencerdawkins> and I just plugged in a new headset, so my voice may be odd at first, feedback is graciously appreciated ...
[15:35:45] <mnot> Bit tinny
[15:36:16] <hardie> This assumes that browsers are the only source of traffic, which isn't true even for HTTPS, since mobile clients could do it (hello, user space transport).  
[15:36:33] <hardie> (This=Lars' statement)
[15:36:36] <Jari Arkko> +1 hardie
[15:37:43] <spencerdawkins> @mnot, thanks for the feedback. I'm still switching audio paths. I may switch again.
[15:40:05] spencerdawkins leaves the room: Disconnected: closed
[15:40:27] <Martin Thomson> we will each make our own assessment
[15:40:38] <Jari Arkko> Offline comment — one needs obviously producers of information and users of information, whenever we standardise anything. However, fortunately less than 100% deployment can provide benefits. Also deployment may change in the future. And agree with Mirja's point.
[15:40:50] <Martin Thomson> the point of this meeting was to provide proponents with information on what other would find useful in making their decision
[15:41:02] <Martin Thomson> and this took too long
[15:41:21] <Jari Arkko> Question to chairs — there was an unclear reference to talking about some related issues later during this interim. Under what agenda items would that be? Or did we decide that there will be no further discussion in the interim? I realise that the bigger questions are up for Bangkok.
[15:41:29] <Mirja Kuehlewind> I was just reacting to what Lars said because that was about the criteria to apply to decide how to move on.
[15:42:05] <Jari Arkko> ok - thanks
[15:42:17] <Mirja Kuehlewind> btw. when will the ECN discussion take place? (can we maybe have that tomorrow morning?)
[15:42:47] <Lars Eggert> not sure - let me check
[15:42:51] <janaiyengar> Mirja — the ACK-ECN discussion?
[15:42:55] <Mirja Kuehlewind> yes
[15:43:22] <Martin Thomson> SCTP 2.0
[15:43:31] <brian@trammell.ch> SCTP 1.4
[15:44:09] <Mirja Kuehlewind> IETF-QUIC is what people already use I guess
[15:45:01] <Mirja Kuehlewind> IQv1
[15:45:15] <lucaspardue> iQUIC = "i can't beleive it's not QUIC"
[15:45:22] <Mirja Kuehlewind> :-)
[15:45:55] <brian@trammell.ch> instead of TCP/IP, it's now HQ3/IQ
[15:46:32] ekr leaves the room
[15:46:34] Eric Kinnear leaves the room: Stream reset by peer
[15:46:43] janaiyengar leaves the room: Stream reset by peer
[15:46:51] Lars Eggert leaves the room
[15:47:00] Christian leaves the room
[15:47:05] Martin Thomson leaves the room
[15:47:07] <spencerdawkins> How many bikesheds are within a four-block radius of the meeting?
[15:47:19] brian@trammell.ch leaves the room
[15:48:13] <lucaspardue> I hear electric scooters are the true topic of debate in US these days
[15:55:18] <g.e.montenegro> Is there an etherpad?
[15:55:31] <lucaspardue> minutes on google docs as I understand it
[15:56:45] Mirja Kuehlewind leaves the room
[16:03:31] dkg leaves the room
[16:04:59] hardie leaves the room
[16:05:22] subodh leaves the room: Connection failed: connection closed
[16:05:59] Jari Arkko leaves the room
[16:08:47] Sean Turner leaves the room
[16:17:20] Sean Turner joins the room
[16:17:23] Lars Eggert joins the room
[16:17:53] Sean Turner leaves the room
[16:20:37] Sean Turner joins the room
[16:26:37] lucaspardue leaves the room
[16:32:27] Christian joins the room
[16:34:30] Martin Thomson joins the room
[16:35:06] Lars Eggert leaves the room: Disconnected: Replaced by new connection
[16:35:08] Lars Eggert joins the room
[16:40:39] <spencerdawkins> Gabriel, minutes are at https://docs.google.com/document/d/1qdZu4mksN8yOoIZPUKXC5GyzuDyEt3DWgjx-ZZOm8gM/edit#
[16:41:44] janaiyengar joins the room
[16:43:37] lucaspardue joins the room
[16:45:18] <Sean Turner> we've not yet starte
[16:45:20] <Sean Turner> d
[16:45:26] ted.h joins the room
[16:45:43] <Sean Turner> We just heard you ted - we haven't quite started yet
[16:46:31] <ted.h> Okay.  I can see the conversation between Kaz & Martin, but not hear it, hence the comment.
[16:48:45] Eric Kinnear joins the room
[16:48:58] brian@trammell.ch joins the room
[16:50:34] subodh joins the room
[16:50:38] <ted.h> I take it moving the mic away from Lars' drum set didn't work out.
[16:51:21] <g.e.montenegro> @spencer: thanks!
[16:52:45] ekr joins the room
[16:53:44] subodh leaves the room: Stream closed by us: Replaced by new connection (conflict)
[16:53:46] subodh joins the room
[16:54:16] <brian@trammell.ch> minutes at https://docs.google.com/document/d/1qdZu4mksN8yOoIZPUKXC5GyzuDyEt3DWgjx-ZZOm8gM/edit#
[16:54:41] Lars Eggert leaves the room: Disconnected: Replaced by new connection
[16:54:43] Lars Eggert joins the room
[17:16:08] <ted.h> So, now this is not speed dating, but going to later in the agenda, right?
[17:16:15] <ekr> hardie; correct
[17:16:19] <ted.h> Thanks
[17:22:26] <ted.h> lost audio
[17:22:42] <ted.h> And it's back.
[17:23:42] Igor Lubashev joins the room
[17:23:50] <Martin Thomson> extension to Retry: please tell me how big your DoS attack is?
[17:25:29] <afrind> https://docs.google.com/spreadsheets/d/1zpOWVNd_t8iEYsQJD8MEMHOkkJ3U1w7yx6furjw3iTw/edit#gid=0
[17:27:26] Igor Lubashev leaves the room: Disconnected: timeout during writing
[17:41:45] <lucaspardue> what transport features does HTTP/QUIC really need? I posit there is low hanging HTTP/QUIC fruit that we could catch with running some interop in parallel
[17:48:25] <Sean Turner> If you're not talking please MUTE!
[17:48:36] <Sean Turner> somebody is shuffling papers
[17:50:05] ekr leaves the room
[17:51:47] subodh leaves the room: Stream reset by peer
[17:51:49] ekr joins the room
[17:52:06] subodh joins the room
[17:58:53] <ted.h> Current speaker is not really audible
[18:01:11] <ted.h> Another advantage to remote participation:  no trial by combat risk.
[18:03:32] subodh leaves the room: Stream reset by peer
[18:03:41] subodh joins the room
[18:05:04] <ted.h> A regular die can make this decision as 1,2; 3-4; 5-6.  DMs everywhere know this trick.
[18:07:31] <g.e.montenegro> hum
[18:07:39] <Martin Thomson> gabriel, I assume that's "do nothing"
[18:07:41] <ted.h> hum for do Alan to pick
[18:07:42] <lucaspardue> hum
[18:07:50] <g.e.montenegro> @MT: yes: do nothing
[18:07:52] <Martin Thomson> lucas: that's do something?
[18:07:58] <spencerdawkins> Could someone promise me that "QUIC took two hums, one to do nothing, and one to do something" will be in the minutes? Because that will be amazing ...
[18:09:00] <Martin Thomson> that's for the minutes: "nobody REALLY cares"
[18:09:25] <spencerdawkins> Even better, with no context :-)
[18:10:20] <janaiyengar> It's only early afternoon on the first day, and we've already hit "nobody REALLY cares"
[18:10:28] <janaiyengar> time to finalize spin bit?
[18:18:05] <spencerdawkins> @jana - bwahahahaha!
[18:19:26] <ted.h> Clarifying question: Thinking about this force feeding question, if recipient of NCID sends RETIRE_CONNECTION_ID, could the respondent refresh with the same IDs?  
[18:20:22] <ted.h> Then let's make it forbidden.
[18:22:50] <ted.h> I was worried about the case where the recipient gets 64 and needs 8, so retires 56, but the sender has logic that says "always keep client at 64".  Refreshing with the same CIDs might occur if the semantic RETIRE_CONNECTION_ID was 'won't be used', but if the assumed semantic is "burned", then we should make it forbidden to resend.  The upshot of that, though, is you have to track those you sent even after they have been retired.  Certainly doable, but let's make sure that code path is the default.
[18:23:08] subodh leaves the room: Stream closed by us: Replaced by new connection (conflict)
[18:23:12] subodh joins the room
[18:25:06] <ted.h> q+
[18:26:01] <ted.h> q-; as a different transparent parameter, don't have an issue.
[18:30:59] Christian leaves the room: Disconnected: Replaced by new connection
[18:30:59] Christian joins the room
[18:48:34] masaori@xmpp.jp leaves the room
[18:48:44] Eric Kinnear leaves the room: Stream reset by peer
[18:48:44] Martin Thomson leaves the room
[18:48:52] ekr leaves the room
[18:50:36] brian@trammell.ch leaves the room: Disconnected: closed
[18:55:17] lucaspardue leaves the room
[19:06:11] subodh leaves the room: Connection failed: connection closed
[19:07:52] ekr joins the room
[19:08:03] Martin Thomson joins the room
[19:08:24] brian@trammell.ch joins the room
[19:09:38] subodh joins the room
[19:10:33] Eric Kinnear joins the room
[19:10:33] <ted.h> Other outcome being:  agree to grease all of them, in advance of decision?
[19:15:06] subodh leaves the room: Stream closed by us: Replaced by new connection (conflict)
[19:15:08] subodh joins the room
[19:20:32] brian@trammell.ch leaves the room
[19:21:25] brian@trammell.ch joins the room
[19:23:01] lucaspardue joins the room
[19:28:18] Martin Thomson leaves the room
[19:41:59] Jari Arkko joins the room
[19:42:10] Martin Thomson joins the room
[19:52:04] Jari Arkko leaves the room
[19:53:30] <ted.h> I really don't want to start seeing semantic connection ids.
[19:54:19] <ted.h> (The semantics of who generated is fine, but the "this is from ASN XXXX, customer YYYY," +random, things are not great)
[19:54:51] <Martin Thomson> the linkability concerns with that are pretty dire
[20:01:22] <Martin Thomson> the number of trials is dictated by the number of servers
[20:01:25] <Martin Thomson> not the size of the hash
[20:11:23] subodh leaves the room: Stream reset by peer
[20:11:35] subodh joins the room
[20:17:19] <ted.h> q+
[20:17:26] <mnot> ack
[20:22:07] <Martin Thomson> they could add a shim!
[20:24:10] <ted.h> I think the shim approach is off the table within the group, frankly, 'cause we're not adding a shim to the invariants.
[20:26:25] <Martin Thomson> I don't think that's right; it's a solution for the stated problem that doesn't involve changing invariants
[20:27:39] <ted.h> @Martin  If you mean the room says "we're not changing the invariants, you can work around it with a shim of whatever design fits your app", we agree.  But I don't think it's up to us to design the shim for this use case (certainly as new work at this stage of v1)
[20:28:21] <Martin Thomson> Oh, that I agree with
[20:28:53] <ted.h> q+
[20:40:27] <ted.h> bleach
[20:41:12] <ted.h> (For the usb shares, I recommend thermite, as it gets the object to the curie point quickly.  Also very entertaining for onlookers!)
[20:41:36] subodh leaves the room: Stream reset by peer
[20:41:49] subodh joins the room
[20:49:17] <lucaspardue> please take this to list, I know some memers of the WG not present would be interested in discussing this concept
[20:49:30] <brian@trammell.ch> +1
[20:49:51] Eric Kinnear leaves the room: Stream reset by peer
[20:49:52] ekr leaves the room
[20:50:05] ekr joins the room
[20:50:59] <lucaspardue> there is much application context that is lost in packet dumps
[20:51:34] Christian leaves the room: Disconnected: Replaced by new connection
[20:51:34] Christian joins the room
[20:55:06] ekr leaves the room
[20:55:34] ted.h leaves the room
[20:55:38] Christian leaves the room
[20:55:41] Lars Eggert leaves the room
[20:56:04] Martin Thomson leaves the room
[20:56:09] g.e.montenegro leaves the room
[20:56:18] Sean Turner leaves the room
[20:56:21] chi.jiun.su leaves the room: offline
[20:57:01] lucaspardue leaves the room
[20:57:18] afrind leaves the room: Stream reset by peer
[20:57:52] janaiyengar leaves the room: Stream reset by peer
[21:00:39] mnot leaves the room
[21:03:45] brian@trammell.ch leaves the room: Disconnected: closed
[21:09:36] subodh leaves the room: Connection failed: connection closed
[21:13:35] Igor Lubashev leaves the room: Disconnected: closed
[21:21:15] mnot joins the room
[21:22:07] ekr joins the room
[21:28:31] mnot leaves the room
[21:33:34] ekr leaves the room
[21:33:38] ekr joins the room
[21:35:18] ekr leaves the room
[21:37:09] Sean Turner joins the room
[21:37:37] Sean Turner leaves the room
[21:39:42] Sean Turner joins the room
[21:53:28] ekr joins the room
[22:02:41] ekr leaves the room
[22:37:11] Sean Turner leaves the room
[22:50:10] Sean Turner joins the room
[22:50:37] Sean Turner leaves the room
[22:51:49] Sean Turner joins the room
[22:57:10] Sean Turner leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!