IETF
QUIC
quic@jabber.ietf.org
Wednesday, June 6, 2018< ^ >
aaron (jabber scribe) has set the subject to: adjourn
Room Configuration
Room Occupants

GMT+0
[07:31:01] chi.jiun.su joins the room
[07:33:46] brian@trammell.ch joins the room
[07:33:56] Sean Turner joins the room
[07:34:03] <Sean Turner> tada!
[07:34:15] spencerdawkins joins the room
[07:34:15] Martin Thomson joins the room
[07:34:21] <brian@trammell.ch> goooooooooooooood morning kista
[07:34:25] Lars joins the room
[07:34:28] lucaspardue joins the room
[07:34:36] <Sean Turner> //topic:Kistaaaaa!
[07:34:45] Martin Thomson has set the subject to: It is pronounced Shyster
[07:34:58] <Sean Turner> //topic:Kista(aka Shista)
[07:35:24] <Christian> Shista-ppends
[07:35:45] masaori@xmpp.jp joins the room
[07:36:24] <Christian> different wi-fi here...
[07:36:39] g.e.montenegro joins the room
[07:36:44] ekr joins the room
[07:36:49] <ekr> Minutes:
[07:36:49] <ekr> https://docs.google.com/document/d/1-2aBorKh9WVE3jM5mBlYNliJH0Ef_gp3dJo0RBe9y4c/edit?usp=sharing
[07:38:07] afrind joins the room
[07:39:43] dtikhonov joins the room
[07:39:44] dtikhonov leaves the room
[07:40:40] dtikhonov joins the room
[07:41:35] <Sean Turner> can you hear okay?
[07:41:45] <chi.jiun.su> yes
[07:42:14] mnot joins the room
[07:46:16] craigt joins the room
[07:47:42] Magnus Westerlund joins the room
[07:48:32] <spencerdawkins> I'm hearing Mark well, and others less well. Is everyone else hearing OK?
[07:49:20] Roberto joins the room
[07:49:20] <Christian> Was OK for me
[07:49:34] <dtikhonov> Agreed: louder is better
[07:49:50] <Roberto> Headphones have helped me to hear the further folks out. Mark and people near him are pretty clear
[07:50:44] <spencerdawkins> Yeah, I'm definitely using headphones for this. Turning my local volume up, too.
[07:51:58] janaiyengar joins the room
[07:52:19] <Martin Thomson> can you see the presentation?
[07:52:21] <chi.jiun.su> yes
[07:52:22] <Roberto> ya
[07:52:29] <dtikhonov> Yes, can see it.
[07:52:29] <Roberto> Stream0 DT Summary.. QUIC Interim.
[07:52:32] <Roberto> I can hear him OK.
[07:55:12] <Martin Thomson> the strikethrough here is odd
[07:55:21] <ekr> I think it’s just a font issue
[07:55:22] <janaiyengar> I don't think it's strikethrough
[07:55:28] <Martin Thomson> it seems like there is some issue with rendering "e"
[07:55:32] <ekr> Unlise we are striking out “the”
[07:56:08] <Christian> no strike through in the google doc
[07:56:46] <Roberto> consistently the 4 characters before the e
[07:57:01] <Roberto> (including the e)
[07:57:40] <Martin Thomson> extreme ligatures
[07:57:53] <Roberto> E for !!Extreme!!
[07:58:15] <Martin Thomson> note that the 1-RTT keys at the different levels are different, not the same, as the diagram implies
[07:58:24] <ekr> Yeah
[07:58:33] <ekr> We should have done two colors
[07:59:03] <Roberto> QUIC. the 'I' is for Inception? Quick UDP Incepted Protocl?
[07:59:16] <ekr> I think Internet
[07:59:26] <janaiyengar> Cna we please remove UDP from the name?
[07:59:47] <ekr> Well, we can just say it’s not an acryonym
[07:59:52] <janaiyengar> we do, no?
[07:59:54] <Roberto> Quality Undeveloped Internet Protocol?
[07:59:54] <ekr> It’s just QUIC
[07:59:56] <Martin Thomson> Queer Unicorn Internet Crap
[07:59:58] <Roberto> We already did, IIRC.
[08:00:12] <Roberto> All acronyms at this point are for giggles.
[08:00:15] <Martin Thomson> it's not an acronym, the doc even says that
[08:00:26] <ekr> “   QUIC is a name, not an acronym.”
[08:00:46] <Martin Thomson> I like to say that "QUIC is just a name, but we do insist that people shout it"
[08:00:53] <Roberto> Muahaha
[08:01:23] <janaiyengar> Hey, that works. The capitalization does it
[08:01:47] ihlar joins the room
[08:01:55] <Christian> Quantum Universal Interblockchain Community
[08:02:16] <Roberto> BLockchain? I'll bet we can get people to invest in this protocol now...
[08:02:16] <brian@trammell.ch> for academics, the following footnote will answer reviewer requests that one properly expand the acronym on its first use: QUIC\footnote{Though ``QUIC'' was initially an acronym for `Quick \acs{UDP}
Internet Connections', current consensus in the \ac{IETF} working group is
that ``QUIC'' is a proper name with no expansion.}
[08:03:40] <Christian> WE want to put Cream-crack interop on the schedule for Montreal!
[08:04:43] <ekr> Well -13
[08:05:02] <Christian> Yes to 13
[08:05:12] <ekr> Kazuho and I have branches up
[08:05:24] <janaiyengar> the plan is to do all this in -13
[08:05:50] <Christian> I discussed this woth Kazuho over slack
[08:06:06] <Christian> I think I can get Picoquic there in a couple weeks
[08:06:19] <janaiyengar> nice
[08:06:46] <ekr> Cool
[08:07:57] <Christian> On the ack multiple layer issues -- we were still finding 0-RTT ack issues during this interop
[08:10:21] <ekr> Yep.
[08:10:29] <ekr> This was like super-clean with separate spaces
[08:10:36] ted.h joins the room
[08:11:05] <Christian> My only concern with the multiple spaces is the impact on the size of the connection context.
[08:11:17] <Christian> But that can probably be optimized away
[08:11:20] <ekr> Yes
[08:11:58] <Roberto> If you couldn't have two packet '2's, then you don't have separate packet number spaces...
[08:12:35] Roberto nods along, feels a bit like headbanging at a concert...
[08:13:03] <ted.h> Can someone move the mic closer to Ian a bit?  Or move Ian's volume dial up a bit?
[08:13:14] <ted.h> Thank you, ekr.
[08:13:21] <ekr> Glad to hear that it had an impact
[08:13:23] <Roberto> That helps a little. Thanks
[08:13:37] <ekr> Next step is to like tape it to his cheek
[08:14:46] dtikhonov notes that sent_packets data structure can be eight bytes
[08:15:30] <Christian> can I ask a question?
[08:15:30] <Roberto> Different random numbers can still overlap, so much better to force the implementer to do the right thing! Nice!
[08:17:23] <ted.h> While Christian's mic is open, hard to hear the room.
[08:17:25] <Magnus Westerlund> Christian how bad was the echo when you where speaking? ?
[08:17:41] <Roberto> Not that bad. IT actually killed some of the echo that was in the room otherwise.
[08:17:50] <Christian> On my side, not so much, I have headphones
[08:17:54] <Roberto> (with mic close to Ian, ekr echoes a bit).
[08:18:57] <Magnus Westerlund> I think the echo canceller struggled with the accoustic echo due to the multiple microphones, but it is very hard to do anything about it when you have omnidirecitonal microphones.
[08:19:14] <Martin Thomson> does this need a length?
[08:19:37] <ekr> The token length is there to tell you that there’s no token
[08:19:47] <Roberto> Also, ekr's voice is lower pitched; echo cancellation of longer wavelengths is more difficult.
[08:19:52] <Martin Thomson> that's fine for Initial, but Retry doesn't need a length
[08:20:06] <ekr> I think you’re right.
[08:20:09] <ekr> Trying to remember.
[08:20:12] <ted.h> What does short-lived mean here?
[08:20:28] <ekr> Basically the duration of the connection (whatever that means)
[08:20:37] <Martin Thomson> the connection establishment really
[08:20:44] <ekr> It’s not expected to be usable in the future
[08:20:49] <Martin Thomson> it's good for one round trip ideally
[08:20:50] <ted.h> So, 3xRTT in a common state?
[08:20:57] <ekr> Sure.
[08:20:58] <Martin Thomson> probably 3RTT yeah
[08:23:57] <Christian> Queztion to Ian: why not make the connection-ID the token?
[08:25:25] <Christian> Question???
[08:25:46] mnot joins the room
[08:25:52] <Christian> Do I need to push Ian off his chair to get the floor?
[08:26:32] <ted.h> The tokens may have semantic data, but are not required to have one?
[08:26:39] <ted.h> er, have any?
[08:28:39] <Christian> I like that design, seems straightforward enough. Also, no Dos amplification
[08:37:08] <brian@trammell.ch> the bikeshed must have two colors!
[08:37:19] <Roberto> Nice job, team.
[08:37:54] Martin Thomson leaves the room
[08:38:09] <Christian> So Mark, do you actually have a wooden boat in the shed?
[08:38:38] <ted.h> I think it was PHK who had the boat shed
[08:38:42] brian@trammell.ch leaves the room: Disconnected: closed
[08:39:14] <janaiyengar> Yes, this design moves DoS protection into the transport, which is quite nice.
[08:41:59] craigt leaves the room
[08:42:09] ekr leaves the room
[08:42:13] janaiyengar leaves the room: Stream reset by peer
[08:44:49] mnot leaves the room
[08:51:26] Sean Turner leaves the room: Replaced by new connection
[08:51:30] Sean Turner joins the room
[08:52:02] Sean Turner leaves the room
[08:53:31] ekr joins the room
[08:54:20] <ted.h> It's amusing to hear the live-mic conversations during the break.
[08:54:41] <Roberto> heh
[08:55:05] <ted.h> And to note that time-keeping has never been our strong suit.
[08:55:17] brian@trammell.ch joins the room
[08:55:20] gryning joins the room
[08:55:25] <ekr> Ted: Delete that
[08:55:44] janaiyengar joins the room
[08:55:52] Martin Thomson joins the room
[08:57:49] <Roberto> yo
[08:58:34] Sean Turner joins the room
[08:59:04] <Roberto> Adopt.
[08:59:13] <Christian> Adopt
[08:59:33] mnot joins the room
[09:00:09] <Roberto> I think that would be useful. I don't think it should change my opinion about the general shape.
[09:04:29] <ted.h> Early on, there was a statement that the security properties of this approach would be essentially similar to those of DTLS (which, given the record layer=QUIC packet layer makes some sense).  What/who will take to do the analysis to demonstrate that?  There seem to be subtleties there vs. standard TLS (records don't have to match packet boundaries, even if padding isn't common).  It would be useful to confirm those don't change the overall properties.
[09:05:02] <ted.h> Yes
[09:05:43] gryning is now known as craigt
[09:06:26] <Sean Turner> ekr takes action to liaise with the academics
[09:06:51] <dtikhonov> Adopt
[09:17:36] <Christian> Second what Jana said. I don't know how to solve the packet shadowing attack if the implementation wants to do client auth.
[09:18:29] <Roberto> The complexity here must be solved somewhere. This seems to make it easier to solve *for real* rather than later, where we discover more issues.
[09:19:23] <ted.h> MIC:  There are two types of adoption: adoption of HTTP/QUIC.  Not terribly concerned there.  For Other/QUIC, though, there are other schedule issues.  Several of these are going forward and I am concerned about the risk of forking/continued maintenance of gQUIC.  If this doesn't create further slippage than what's already happened, then this is moot.  But I think there's a real issue to watch  here, and I'm not sure the WG can/is watching it, given those folks were asked to wait to bring their work here (in the charter text).
[09:20:03] <Roberto> you mean IETF/QUIC? Or do you mean HTTP/QUIC?
[09:20:39] <ted.h> HTTP over QUIC
[09:21:45] <Roberto> thx
[09:22:42] <Christian> Nice understatement, Gabriel
[09:22:50] <Martin Thomson> resounding agreement from the room there
[09:23:06] <ted.h> Yeah, that was a serious understatement.  Practically British.
[09:23:10] <janaiyengar> To be clear, I think this proposal solves issues that were left open when QUIC decided to move away from QUIC Crypto to using TLS. The mapping was never fully done correctly, and this actually closes the loop.
[09:23:48] <Roberto> Yup
[09:24:11] <ted.h> Apologies for the request, but can Mike Bishop move the mic a bit further away?  When he coughs, it blows out the sound level for me as a remote.
[09:24:27] <mnot> He’s not very close
[09:24:30] <ekr> Yeah.
[09:24:34] <ted.h> Powerful lungs, then.
[09:24:40] <ted.h> Don't change that.
[09:24:42] <ekr> It’s like BIshop - Swett - mic - Me
[09:25:28] <Roberto> Adopt the overall direction.
[09:25:58] <ted.h> I'm more in the "abstain" column than object.
[09:31:25] Martin Thomson leaves the room
[09:32:05] Martin Thomson joins the room
[09:40:07] <Roberto> TCP -> TLS -> App.
[09:40:11] <Roberto> Here,
[09:40:19] <Roberto> Encryption -> Transport -> App.
[09:40:26] <Roberto> Bottom two layers are inverted.
[09:41:02] <Roberto> Thus, must either use non-transport TLS underneath transport.
[09:41:10] <Roberto> or roll encryption with transport.
[09:48:06] <Roberto> I note this is essentially the issue with inversion/deadlock that caused us to have no flow-control on control messages for H2.
[09:51:39] <Roberto> *raises hand*
[09:52:18] <Roberto> tech difficulties.
[09:56:56] <Roberto> sgtm too
[09:56:56] <Lars> /subject IETF QUIC WG
[09:57:13] <ted.h> @Lars I think you mean /topic
[09:57:20] <Roberto> accept Martin's proposal.
[09:57:21] Lars has set the subject to: IETF QUIC WG
[09:57:27] <Lars> i guess i do :-) thanks
[09:58:00] <Christian> Punt to TLS WG? Yes, that sounds OK.
[09:58:15] Jari Arkko joins the room
[09:59:19] <Roberto> Seems like a nice "optional" feature.
[09:59:24] <Roberto> How do you grease it? 🙂
[09:59:24] <Jari Arkko> FWIW, I also like the punt-to-the-TLS WG solution. Other protocols that use TLS might also benefit from any TLS-based solution (e.g., EAP TLS).
[09:59:33] <Martin Thomson> To be clear, I'm not suggesting that the QUIC working group ask the TLS working group to solve the problem. Just that those who believe that the problem is worth solving work on a generic solution for TLS and that those people should go straight to the TLS working group.
[10:00:47] <Sean Turner> MT: Yep that's how I took it
[10:01:35] <Martin Thomson> That's good, because you'll be on the receiving end. :)
[10:02:56] <Sean Turner> exactly :)
[10:03:23] brian@trammell.ch leaves the room
[10:03:24] brian@trammell.ch joins the room
[10:04:57] <Christian> What Roberto says. Just punt
[10:05:23] <Martin Thomson> I confess that I don't understand Kazuho's proposed hack.
[10:05:35] <ted.h> I like that formulation—is there a strong reason not to punt?
[10:06:57] <Christian> I think I do. Always put a small HS packet in front of the early 1-RTT packet. So if you can ACk the HS packet and deduce holes, etc.
[10:08:41] <janaiyengar> Christian, so in this case, you'd basically throw a PING frame in a HS packet in front?
[10:08:45] <Roberto> "forever" is a dirty word.
[10:09:14] <Christian> @janaiyengar: Yes.
[10:09:18] <dtikhonov> Why "forever?"  How is this diffferent from keeping two sets of keys when key phase changes?
[10:10:43] <ted.h> Yeah, implicit acks are not really a great design choice here (imagine me holding a coffee cup and leaning over a cube, if you must).
[10:13:26] <Roberto> I've seen that so many times, it is more of a memory than a figment of imagination 🙂
[10:16:00] <Christian> I have been asking for something like Handshake Ack for a ***long*** time!
[10:17:34] <Christian> Of course there are issues. Like, what if the peer does not do it?
[10:18:02] <Roberto> Yup
[10:18:12] <Roberto> I'm pretty
[10:18:36] <janaiyengar> I'm glad you feel that way Roberto
[10:18:36] <Roberto> *I'm pretty "meh" about this. Again an optimization. Seems like something an attacker will have fun not sending.
[10:18:41] <Roberto> rofl
[10:19:16] <mnot> Was picturing Roberto as childish gambino for a sec there...
[10:19:27] <janaiyengar> nice
[10:19:37] <Roberto> With this croaky voice. Oh, the dissonance!
[10:20:25] <Roberto> *raising hand*
[10:21:08] <mnot> Ack
[10:22:53] <janaiyengar> Christian, do you have thoughts?
[10:24:05] <Roberto> padding.
[10:24:08] <Christian> I would like to see a complete security analysis. I am not as concerned as Roberto
[10:24:16] <Roberto> padding is great for when you need to say something, but have nothing to say.
[10:24:17] Magnus Westerlund leaves the room
[10:24:25] <janaiyengar> PING is better
[10:24:46] <Christian> ... but I would like some behavior, such as "acking an HD is equivalent to sending one."
[10:25:27] <Roberto> So long as it is the normal and only path here, I'd support it. If it wasn't always in use, it'd be a fun vector for attack.
[10:26:27] <Christian> If you adopt the ACK rule, then any party can send one, and if the peer never acks the packet the connection breaks. That seems strong enough.
[10:28:24] <Roberto> Yes. Either you'
[10:28:34] <Roberto> Either you've received data, or you wait for a timeout, and that is it.
[10:29:55] <Roberto> Note that HTTP on QUIC will likely not exercise this.
[10:30:11] <Roberto> Thus, there is some thought we'll have to put in to ensure this is exercised.
[10:30:33] <Roberto> yes; be explicit!.
[10:30:46] <ted.h> +1 be explicit
[10:31:30] <Roberto> yes, that is good. But, be aware of the caveat that HTTP in the browser will likely NOT exercise the 2MSL timeout...
[10:33:40] janaiyengar leaves the room: Stream reset by peer
[10:34:02] ihlar leaves the room
[10:34:16] ekr leaves the room
[10:34:18] Sean Turner leaves the room
[10:34:27] lucaspardue leaves the room
[10:34:29] Lars leaves the room
[10:34:46] craigt leaves the room
[10:34:52] mnot leaves the room: Disconnected: closed
[10:35:00] Martin Thomson leaves the room
[10:35:42] mnot leaves the room
[10:35:47] brian@trammell.ch leaves the room: Disconnected: closed
[10:35:56] Jari Arkko leaves the room
[10:41:49] Jari Arkko joins the room
[10:44:57] ted.h leaves the room
[11:40:42] Sean Turner joins the room
[11:42:41] masaori@xmpp.jp leaves the room
[11:42:44] masaori@xmpp.jp joins the room
[11:44:24] masaori@xmpp.jp leaves the room
[11:44:25] masaori@xmpp.jp joins the room
[11:44:42] masaori@xmpp.jp leaves the room
[11:44:44] masaori@xmpp.jp joins the room
[11:47:57] Martin Thomson joins the room
[11:48:11] mnot joins the room
[11:48:33] lucaspardue joins the room
[11:49:23] ekr joins the room
[11:54:53] gryning joins the room
[11:57:52] <dtikhonov> No slides?
[11:57:52] Lars joins the room
[11:57:57] brian@trammell.ch joins the room
[11:57:58] <ekr> No
[11:57:59] <mnot> No slides
[11:59:08] ihlar joins the room
[12:00:42] <mnot> Remote folks, please say if you have trouble hearing, or if there’s too much noise etc.
[12:03:12] <dtikhonov> The people should speak up a bit
[12:03:21] <mnot> ack
[12:04:32] janaiyengar joins the room
[12:05:45] gryning is now known as craigt
[12:06:40] <dtikhonov> MIC: ACK processing is rather expensive.  I think it would be better if the packets were separated into different namespaces to make the ACK processing loop simpler.  Thus, my preference would be to have different namespaces for packet numbers.
[12:08:10] <mnot> ack
[12:08:23] <Christian> If hanshake packets are protected by the handshake key, I am a lot less concerned with the possible packet shadow attack.
[12:09:21] <Christian> And having a single number space would be very nice
[12:10:26] Jari Arkko leaves the room
[12:12:05] <ekr> @mnot:I just added my slides with the flows that Duke requested
[12:12:29] <mnot> When would you like to do that -- this afternoon late, or tomorrow?
[12:12:46] <ekr> Entirely up to you
[12:12:57] <ekr> Thanks to Kazuho for hishelp
[12:13:58] <Martin Thomson> ekr's hat is on top of the mic?
[12:15:03] <Roberto> Raised hand for question: How does a NIC with theoretical QUIC acceleration know when to hand off stuff to userspace?
[12:15:43] <Roberto> Because I can reason about this more simply with a multiple-packet-sequence space tied to epochs/keys.
[12:15:52] <Roberto> I don't know how to deal with it otherwise?
[12:16:44] Magnus Westerlund joins the room
[12:19:13] <Roberto> Careful with that.
[12:21:18] <Roberto> IF you allow PN to start from an arbitrary number, it should be explicit.
[12:21:26] <Roberto> (in the spec)
[12:30:48] ihlar leaves the room
[12:37:29] Jari Arkko joins the room
[12:47:27] <lucaspardue> Flags removal PR: https://github.com/quicwg/base-drafts/pull/1398
[12:48:49] ihlar joins the room
[12:49:36] ihlar leaves the room
[12:52:28] <lucaspardue> Unidirectional stream headers PR: https://github.com/quicwg/base-drafts/pull/1359
[12:53:06] <dtikhonov> *raise hand* for an objection to the type business when it's time
[12:53:21] brian@trammell.ch leaves the room: Disconnected: closed
[12:55:26] <Roberto> *hand raised*
[12:58:47] <Roberto> I understand it is nice in terms of self-description/extensibility.
[12:58:55] Martin Thomson leaves the room
[12:59:06] <Roberto> I do worry about debugging sessions from the middle.
[12:59:31] <Roberto> I'm not as worried about the in-order/ordered thing (you need the beginning of most streams to figure that one out right now)
[12:59:39] <Roberto> In v2, I'd worry about it.
[13:00:24] <Roberto> *raise hand* (someone else can say it)>
[13:00:29] <Roberto> This is flags on a per stream basis.
[13:00:38] brian@trammell.ch joins the room
[13:02:45] <Roberto> I'm not actually against having the self-describing streams.
[13:02:58] <Roberto> I'm just trying to reconcile them with the other parts.
[13:03:52] <Roberto> .. and streams are the units on which we do priority.
[13:05:26] <dtikhonov> MIC: A networked computer is an analogy.  Port 80 is HTTP, 22 is SSH, and so on.  We don't examine first byte of each TCP connection to see what it is.  TCP connetions have ports, streams have IDs.  Use them.
[13:06:07] <Roberto> The counter-example is port 80 UDP 🙂
[13:06:57] <Roberto> I don't know how you can ensure that you accept streams in-order without introduce head-of-line blocking.
[13:07:53] <Roberto> *raise hand*
[13:08:32] Martin Thomson joins the room
[13:13:33] <ekr> are we getting close to break time?
[13:13:44] <janaiyengar> yes
[13:13:50] <janaiyengar> we are closer than we were earlier
[13:14:23] <Roberto> humm: dunno yet.
[13:17:48] <Roberto> Zombie says: Priority Hard. PRIORITY HARD!
[13:19:10] <Roberto> Love the arrow 'polarities' there 😉 Muahahha
[13:20:24] <dtikhonov> That's right: the whole priority/dependency thing is advisory
[13:21:42] <lucaspardue> @Roberto: does this relate to some of the stuff you presented in Melbourne?
[13:21:57] <Roberto> I think it kinda does, ya.
[13:22:09] <Roberto> To me this translates to:
[13:22:18] <Roberto> There is priority for the data that a stream carries
[13:22:21] <Roberto> and priority for a stream.
[13:22:29] <Roberto> and these should have been separate, but aren't.
[13:22:42] <Roberto> (and then there is stream groups)
[13:22:58] <Roberto> *raise hand*
[13:23:07] <lucaspardue> ta
[13:23:13] <mnot> ack
[13:23:15] <dtikhonov> MIC: we can do priority, but not do dependencies, since it's the tree part that's hard.
[13:23:59] ekr leaves the room
[13:26:12] <Martin Thomson> I wonder whether using things that look like a stream ID would work for a placeholder.  You don't need to create the unidirectional stream to use its identifier as a placeholder.
[13:26:39] <Martin Thomson> We currently only prioritize server unidirectional and client bidirectional streams
[13:27:07] <lucaspardue> the proxy chaining use case is also interesting
[13:27:38] <Martin Thomson> lucaspardue: you should raise that point, because part of the reason we have this complexity in priority in h2 is the proxy case
[13:27:42] ekr joins the room
[13:27:57] <dtikhonov> Sure, we can use three bits and limit the range of stream IDs to 2^61 - 1 :)
[13:28:09] <afrind> spdy/2 got it right with 2 bits
[13:28:16] <ekr> 3 bits
[13:28:21] <ekr> super-high
[13:28:27] <Martin Thomson> 2.4 bits
[13:28:28] <ekr> and “i don’t ever want to receive this”
[13:29:18] <Roberto> *raise hand*
[13:30:34] <dtikhonov> Roberto, +1
[13:30:38] subodh joins the room
[13:31:04] <lucaspardue> @Martin: I need to think more about it, I've only considered an HTTP/QUIC proxy does blind relaying (i.e. there is no h2c equivalent for QUIC)
[13:32:16] <craigt> Is priority expected this is entirely transport, or there will be userspace APIs for this? Surely if the former just quic is fine...if the latter, then consistency acroos quic/h2 would make sense
[13:32:22] dtikhonov likes the slide.  "Time is money?"
[13:33:04] <subodh> less is more
[13:33:57] <Roberto> I'd rather have one wrong thing than two wrong things.
[13:34:08] <Roberto> Do we think about this for Q2?
[13:34:10] <ekr> @grmocg: don’t they cancel each other out?
[13:34:34] <Roberto> i*i = -1. 🙂
[13:34:40] <craigt> Roberto: indeed
[13:34:46] <ekr> otoh, -1 * -1 = 1!
[13:34:51] <ekr> And three lefts make a right
[13:35:39] <Roberto> e^(2*pi*i)
[13:35:58] craigt leaves the room
[13:36:11] ekr leaves the room
[13:36:23] Martin Thomson leaves the room
[13:38:49] Martin Thomson joins the room
[13:40:15] Martin Thomson leaves the room
[13:54:44] subodh leaves the room: Connection failed: connection closed
[13:54:52] brian@trammell.ch leaves the room
[13:57:40] Roberto leaves the room
[13:58:03] Martin Thomson joins the room
[13:58:50] subodh joins the room
[13:59:25] ekr joins the room
[13:59:26] gryning joins the room
[13:59:40] gryning is now known as craigt
[14:02:47] <dtikhonov> MIC: what's the reason for the framing?  (The length n the encoder stream)
[14:05:49] brian@trammell.ch joins the room
[14:06:00] dtikhonov tries another way
[14:06:03] <dtikhonov> *raise hand*
[14:06:20] <mnot> Ack
[14:06:37] <Martin Thomson> dtikhonov: I had the same question, it's to simplify the decoder
[14:11:06] <dtikhonov> Martin, I understand the reasoning, but it would suck to keep a 16KB buffer around in the decoder "just in case."  As long as the WG is aware of the potential optimization that it kills.
[14:11:21] <dtikhonov> s/decoder/encoder/
[14:12:16] <Martin Thomson> I'm with you: a contiguous stream of instructions would be easier to write
[14:13:45] <Martin Thomson> Also, it is less likely to trip issue #1420
[14:19:00] <dtikhonov> Oh, you filed it 7 minutes ago.  No wonder I haven't seen it.  :)
[14:32:38] subodh leaves the room: Connection failed: connection closed
[14:37:27] <Jari Arkko> +1 to Martin
[14:38:12] ekr leaves the room
[14:38:32] ekr joins the room
[14:38:32] <dtikhonov> The size of this table is virtually free.
[14:40:13] <Martin Thomson> not for a constrained implementation, but yeah, we're close to that
[14:43:05] <dtikhonov> MIC: I think putting it into transport params is the best thing to do -- simply because we can punt it for now and come back to it later.
[14:45:18] <Martin Thomson> a virgin bikeshed
[14:50:56] ekr leaves the room
[14:52:00] ekr joins the room
[14:57:22] ekr leaves the room
[14:57:25] Sean Turner leaves the room
[14:58:01] chi.jiun.su leaves the room: offline
[14:58:04] <dtikhonov> /quic
[14:58:04] <dtikhonov> /quit
[14:58:07] <dtikhonov> /leave
[14:58:10] <dtikhonov> hmm
[14:58:13] masaori@xmpp.jp leaves the room
[14:58:20] <afrind> thanks for staying to the end
[14:58:21] Lars leaves the room
[14:58:35] janaiyengar leaves the room
[14:58:45] <dtikhonov> afrind, sure -- it was interesting.
[14:58:52] mnot leaves the room
[14:58:54] <dtikhonov> Martin filed a new bug for QPACK
[15:00:12] lucaspardue leaves the room
[15:00:15] Magnus Westerlund leaves the room
[15:01:10] Martin Thomson leaves the room
[15:02:56] afrind leaves the room: Stream reset by peer
[15:03:03] craigt leaves the room: Disconnected: closed
[15:03:27] Jari Arkko leaves the room
[15:04:26] dtikhonov leaves the room
[15:06:11] Christian leaves the room
[15:13:43] g.e.montenegro leaves the room
[15:15:44] brian@trammell.ch leaves the room: Disconnected: closed
[15:29:05] ted.h joins the room
[15:58:30] ekr joins the room
[16:20:47] ted.h leaves the room
[16:30:49] ekr leaves the room
[16:36:15] ekr joins the room
[16:44:15] spencerdawkins leaves the room: Disconnected: closed
[17:00:59] ted.h joins the room
[17:08:22] ted.h leaves the room
[17:20:41] ekr leaves the room
[19:00:54] g.e.montenegro joins the room
[19:20:52] afrind joins the room
[19:26:14] ekr joins the room
[19:28:03] afrind leaves the room: Stream reset by peer
[19:28:07] afrind joins the room
[19:36:41] g.e.montenegro leaves the room
[19:40:16] ekr leaves the room
[19:51:59] ekr joins the room
[19:53:19] Jari Arkko joins the room
[19:54:52] afrind leaves the room: Stream reset by peer
[19:54:53] afrind joins the room
[19:55:03] Christian joins the room
[20:09:30] ekr leaves the room
[20:10:41] mnot joins the room
[20:17:48] mnot leaves the room
[20:26:11] afrind leaves the room: Connection failed: connection closed
[20:26:41] mnot joins the room
[20:37:04] mnot leaves the room
[20:39:44] ekr joins the room
[20:40:30] mnot joins the room
[20:45:52] mnot leaves the room
[20:54:00] mnot joins the room
[20:59:22] mnot leaves the room
[21:16:43] lucaspardue joins the room
[21:37:39] Christian leaves the room
[21:40:26] Christian joins the room
[21:41:55] Roberto joins the room
[22:18:09] ekr leaves the room
[22:23:20] lucaspardue leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!