IETF
QUIC
quic@jabber.ietf.org
Wednesday, January 25, 2017< ^ >
Sean Turner has set the subject to: QUIC Interim - 20170124-20170126 | 9:30 am  |  Japan Time (Tokyo, GMT+09:00)  |  8 hrs
Room Configuration
Room Occupants

GMT+0
[00:03:08] gryning@jabber.org.uk joins the room
[00:03:20] Mirja Kuehlewind leaves the room
[00:06:07] hardie@xmpp.rg.net joins the room
[00:07:19] Martin Thomson joins the room
[00:08:20] ekr joins the room
[00:08:34] Katsushi Kobayashi joins the room
[00:12:32] ranjeeth joins the room
[00:14:32] mnot joins the room
[00:14:38] <mnot> ping
[00:15:06] <ranjeeth> reply with ttl 60 s
[00:15:24] <mnot> ack
[00:17:13] jo.ietf joins the room
[00:17:17] <gryning@jabber.org.uk> just me online
[00:17:36] gryning@jabber.org.uk is now known as craigt
[00:18:02] Kaoru Maeda joins the room
[00:18:29] <Daniel> had to get me a fresh cup first!
[00:19:34] Lars Eggert joins the room
[00:19:49] <hardie@xmpp.rg.net> Scribing into a new doc, same access (anonymous with link has edit rights).  New:  https://docs.google.com/document/d/1R6N200VH-tXfc7eNjAFWhBv-tICa_PM0cuTk17B0eTY/edit?usp=sharing
[00:19:58] mcmanus joins the room
[00:20:02] lucasp joins the room
[00:20:33] lstewart joins the room
[00:24:35] <craigt> lost audio
[00:24:41] <craigt> still have video
[00:24:45] <craigt> it's back
[00:24:49] <mnot> changed mics
[00:24:56] <craigt> it's cleaer, thanks
[00:25:29] <craigt> although with that scarf, we'll never hear Mirja
[00:26:01] Mirja Kuehlewind joins the room
[00:26:02] Sean Turner joins the room
[00:26:59] <lucasp> webex has issues letting me join and hear audio without a microphone. So now I've plugged my speakers into the line in and it's happy...
[00:27:16] <Daniel> haha
[00:28:11] <lucasp> last night I was using a laptop just for audio, think of the environment
[00:28:25] Mike Bishop / Mike Bishop joins the room
[00:29:17] <craigt> I resisted the urge to tun the heating on and got under blankets….good job I'm not as bold as Mike with the camera on…would have looked quite ridiculous
[00:31:16] <mnot> starting
[00:31:44] <Sean Turner> noted
[00:31:48] <craigt> and well
[00:31:50] Brian Trammell joins the room
[00:32:14] <Sean Turner> clap!clap!
[00:33:03] <Sean Turner> honestly the scribing yesterday was pretty spot on
[00:35:06] Brian Trammell leaves the room
[00:35:30] g.e.montenegro joins the room
[00:36:40] <craigt> Craig Taylor - BBC
[00:36:53] <lucasp> Lucas Pardue - BBC
[00:37:21] <lstewart> Lawrence Stewart - Netflix (sorry, was AFK for a sec)
[00:37:31] Brian Trammell joins the room
[00:39:06] <Sean Turner> it's also available here:
[00:39:09] <Sean Turner> https://github.com/quicwg/wg-materials/blob/master/interim-17-01/keyphases.pdf
[00:39:13] <mnot> thx sean!
[00:39:21] <craigt> Video/presentation fine remotely ftr
[00:39:23] <Sean Turner> trying to do my part ;)
[00:43:00] afrind joins the room
[00:44:32] <spencerdawkins> Is it my imagination, or are people significantly quieter today than the same people were yesterday? I DID change seats from one side of the room to the other, but I'm the same distance from the most frequent speakers.
[00:44:46] <mnot> I’ll remind folks to speak up.
[00:45:32] Mirja Kuehlewind leaves the room
[00:45:35] <Brian Trammell> i think we're quieter
[00:45:35] <Brian Trammell> had the same impression, and i'm sitting in the same place. it's also possible that the ventilation is louder today.
[00:45:40] <spencerdawkins> thanks!
[00:45:40] <Sean Turner> I figured it was a heavy beer night :)
[00:45:53] <Mike Bishop / Mike Bishop> Or a heavy jet-lag night.  :-)
[00:46:16] <spencerdawkins> Sean, when beer is a sufficient explanation, there's no reason to look further ;-)
[00:50:11] chi.jiun.su joins the room
[00:53:41] Brian Trammell leaves the room: Disconnected: Received SIGTERM
[00:54:04] <spencerdawkins> Is https://docs.google.com/document/d/1yp9EUz2BheZhMai4kAe1mcKq9Sv9rIfpEq_wXaX_Br0/edit still the google docs page for minutes? I'm not seeing updates past yesterday afternoon (and the doc title is QUIC Minutes Jan 24 2017, so I'm especially curious).
[00:54:22] Brian Trammell joins the room
[00:54:25] <mnot> new one -
[00:54:39] <mnot> https://docs.google.com/document/d/1R6N200VH-tXfc7eNjAFWhBv-tICa_PM0cuTk17B0eTY/edit
[00:55:13] <spencerdawkins> Mnot - thanks!
[00:56:17] Dirk Kutscher joins the room
[00:56:31] patrick leaves the room
[01:02:47] <craigt> mnot: Who's talking left of cam please?
[01:02:58] <mnot> that’s subodh I, from facebook
[01:03:05] <mnot> will get a shot of him next time he talks.
[01:03:10] <craigt> Thought so, thank you…
[01:04:30] Dirk Kutscher leaves the room
[01:04:42] Dirk Kutscher joins the room
[01:08:49] Martin Thomson leaves the room
[01:08:51] Martin Thomson joins the room
[01:10:08] <mnot> remote folks, tell me if fan noise from the laptop makes hearing difficult.
[01:10:44] <craigt> nothing obvious to me…
[01:11:52] Brian Trammell leaves the room
[01:16:35] Brian Trammell joins the room
[01:17:50] ranjeeth joins the room
[01:20:38] Martin Thomson leaves the room
[01:20:40] Martin Thomson joins the room
[01:21:52] Mirja Kuehlewind joins the room
[01:22:03] lhedstrom leaves the room
[01:23:19] jo.ietf leaves the room
[01:23:40] Brian Trammell leaves the room: Disconnected: closed
[01:23:50] Dirk Kutscher leaves the room
[01:24:06] lhedstrom joins the room
[01:24:25] Dirk Kutscher joins the room
[01:24:31] Martin Thomson leaves the room
[01:24:33] Martin Thomson joins the room
[01:26:29] Brian Trammell joins the room
[01:26:40] craigt waves at mini-Mike
[01:27:55] spencerdawkins leaves the room
[01:28:04] <Sean Turner> zero checksum is https://datatracker.ietf.org/doc/rfc6936/
[01:28:07] spencerdawkins joins the room
[01:31:46] ranjeeth joins the room
[01:31:57] ranjeeth leaves the room
[01:34:05] Buck Krasic joins the room
[01:38:36] Dirk Kutscher leaves the room
[01:38:51] <Sean Turner> I feel like I should be channeling my inner agl when he says we can do the crypto at line card rates
[01:39:17] <hardie@xmpp.rg.net> Do you want that reflected to the room?
[01:39:38] <Sean Turner> yeah I mean if I'm misremembering ekr will correct me
[01:39:48] Dirk Kutscher joins the room
[01:44:16] Brian Trammell leaves the room
[01:44:23] Brian Trammell joins the room
[01:44:35] <Sean Turner> we have the technology ;)
[01:44:49] <mnot> 10 minute break
[01:45:18] ranjeeth leaves the room
[01:48:33] <lucasp> craig, if you're still feeling cold take a break by the fire http://timer.onlineclock.net/bg/fireplace/
[01:51:54] <Mike Bishop / Mike Bishop> I think I'm still in the chat room, but I just saw an error pop up that we've hit our maximum number of participants.
[01:52:14] <Mike Bishop / Mike Bishop> Do we need to request an increase?
[01:52:20] <lstewart> Jabber or webex?
[01:52:24] <Mike Bishop / Mike Bishop> Jabber.
[01:52:46] <lstewart> I don't see said warning
[01:53:11] <Mike Bishop / Mike Bishop> My participants list also says 25/25 at the top.
[01:54:50] mnot leaves the room
[01:55:35] <Mike Bishop / Mike Bishop> Hm.  And without mnot, it says 24/24.  So maybe that's a red herring.
[01:57:04] Dirk Kutscher leaves the room
[01:58:50] Dirk Kutscher joins the room
[02:01:27] <Daniel> those Japanese 10 minutes certainly can feel longer than regular ones =)
[02:01:46] dragana joins the room
[02:02:08] Mirja Kuehlewind leaves the room
[02:02:20] mnot joins the room
[02:02:21] <Lars Eggert> about to restart
[02:02:22] <craigt> better than european bicuits, clearly
[02:03:46] <mnot> can folks see / hear?
[02:03:51] <craigt> yes thx
[02:04:39] Mirja Kuehlewind joins the room
[02:09:26] <Sean Turner> mic drop!
[02:09:40] <hardie@xmpp.rg.net> You did great, Sean, really.
[02:09:48] Daniel nods over here in the dark
[02:09:52] <mnot> +1
[02:10:11] <hardie@xmpp.rg.net> @Mike do you have slides for me to link into the minutes?
[02:11:23] <Sean Turner> yep
[02:13:14] <mnot> @daniel: we have someone here wearing a curl t-shirt :)
[02:13:31] <Daniel> wohoo
[02:13:47] <lucasp> any Moz://a t-shirts yet?
[02:14:20] <mnot> heh
[02:15:21] <hardie@xmpp.rg.net> There's a Google shirt, but it is a "I don't need Google, my X knows everything."  Haven't seen the value of X.
[02:15:41] <mnot> Forgot to bring my “Nuke the Valley” t-shirt. *shrug*
[02:16:15] <lucasp> X = Theresa May ?
[02:17:18] <Daniel> X = QUIC wg?  :-D
[02:17:32] <mnot> AD
[02:19:32] fujisaki.tomohiro joins the room
[02:22:59] Dirk Kutscher leaves the room
[02:26:31] lhedstrom leaves the room
[02:26:44] lhedstrom joins the room
[02:27:12] lhedstrom leaves the room
[02:27:17] lhedstrom joins the room
[02:27:44] <mnot> remote folks see http/quic presentation?
[02:27:53] <craigt> yes
[02:28:06] <Sean Turner> yep
[02:28:38] <Sean Turner> and it's here too:
[02:28:40] <Sean Turner> https://github.com/quicwg/wg-materials/blob/master/interim-17-01/draft-ietf-quic-transport.pdf
[02:29:05] <Sean Turner> oops wrong slides :(
[02:29:20] <Sean Turner> this one: https://github.com/quicwg/wg-materials/blob/master/interim-17-01/HTTP.pdf
[02:30:14] <mnot> sean, can you mute?
[02:30:30] <Sean Turner> whoops
[02:31:35] <hardie@xmpp.rg.net> QUIC kraal?
[02:32:56] <Sean Turner> ha!
[02:37:39] <lucasp> how often is "v" parameter going to be used? so how many bytes would really be saved in widespread usage?
[02:37:44] spencerdawkins leaves the room
[02:39:51] spencerdawkins joins the room
[02:39:57] Dirk Kutscher joins the room
[02:41:45] spencerdawkins leaves the room
[02:41:48] <Sean Turner> tupac or not tupac
[02:42:10] <mnot> TUPACK?
[02:42:11] spencerdawkins joins the room
[02:42:22] <mnot> Transport Un-order-dependant PACK
[02:42:42] <Daniel> quack
[02:43:00] <Buck Krasic> :)
[02:43:37] spencerdawkins leaves the room
[02:43:55] <craigt> hum for more children present at ietf meets?
[02:44:56] <lucasp> the out-of-order compression I am most used to is the toothpaste tube
[02:46:43] Dirk Kutscher leaves the room
[02:47:25] <Buck Krasic> what is application?  http? or higher?
[02:47:42] <hardie@xmpp.rg.net> HTTP, I think.  Do you want that asked in the room, though?
[02:47:56] Dirk Kutscher joins the room
[02:48:03] <Buck Krasic> maybe just ask to clarify terms
[02:49:40] spencerdawkins joins the room
[02:50:48] <Buck Krasic> I think we should be clear that HoL is probably a tail performance issue.  I'm all for improving tail performance, but I would try to keep complexity of changes down.
[02:51:49] <Buck Krasic> The data we have is that something like ~1% of connections experience HoL.
[02:51:56] <Buck Krasic> on headers
[02:52:44] <lstewart> @Buck: Who's "we"?
[02:53:02] <Buck Krasic> sorry, I meant wg, but of course only speaking for myself
[02:57:20] <Buck Krasic> worth pointing out, no browser uses a size larger than default standard.  point being that in the wild, table size hasn't shown up as a significant performance issue.
[02:59:55] <Buck Krasic> I think the only real problem here is to handle refusing.  
[03:01:44] <mnot> @mike, please have your additional attendee acknowledge the NOTE WELL and sign the blue sheet.
[03:02:45] afrind leaves the room
[03:03:05] Dirk Kutscher leaves the room
[03:04:33] Dirk Kutscher joins the room
[03:04:43] Dirk Kutscher leaves the room
[03:05:31] Mirja Kuehlewind leaves the room
[03:05:57] ekr leaves the room
[03:05:57] Lars Eggert leaves the room: Disconnected: closed
[03:06:09] Brian Trammell leaves the room
[03:09:08] hardie@xmpp.rg.net leaves the room
[03:12:26] mnot leaves the room
[03:13:27] mnot joins the room
[03:13:29] Martin Thomson leaves the room
[03:14:20] ekr joins the room
[03:20:49] <mnot> On break until the top of the hour.
[03:27:49] Martin Thomson joins the room
[03:30:52] mnot leaves the room
[03:32:35] afrind joins the room
[03:34:48] mnot joins the room
[03:35:22] <mnot> ping
[03:35:41] <Mike Bishop / Mike Bishop> I stole the "table size change" code for delete.  If we want to add more commands, we'll need to renumber the entire space.  Not the end of the world, but means we're no longer describing deltas from HPACK.
[03:35:43] <Sean Turner> pong
[03:36:12] lhedstrom leaves the room
[03:36:16] <Mike Bishop / Mike Bishop> Martin had suggested that the eventual thing be written up from scratch instead of deltas anyway, so that's fine.
[03:36:16] <mnot> understood
[03:36:33] <mnot> I’d +1 that - reading it as a delta from HPACK is useful for current discussion, but not long term.
[03:36:42] <Daniel> agreed
[03:36:53] <Mike Bishop / Mike Bishop> Our side discussion can be summarized this way:  Buck has an alternate update that uses HPACK natively but augments the sequence numbers with a different ACK format.
[03:37:02] <mnot> (if you don’t mind some pull requests, I’m happy to help with that)
[03:37:07] <Mike Bishop / Mike Bishop> Both of ours are functional given a couple constraints:
[03:37:56] <Mike Bishop / Mike Bishop> The HTTP layer will NEVER reset a message control stream, only the body.  If the data stream gets RST, that implies you no longer care about the control stream, so you SHOULD FIN it immediately.
[03:38:31] <mnot> Yes. Martin and I were just talking about that; it seems like the real justification for splitting message exchanges into dual streams.
[03:38:37] <Buck Krasic> just to nit.  in mine, there is no special ack format.  simply two "sequence" numbers sent with headers, an encode epoch, and a commit epoch.   the commit is determined by acks, but just regular quic acks.
[03:38:41] <Mike Bishop / Mike Bishop> The QUIC stream will never RST a stream for a reason other than refused, and the HTTP layer MUST (not MAY, as in HTTP/2) re-send *the exact same HPACK frame* on another stream in the future.
[03:39:45] <Mike Bishop / Mike Bishop> Basically, both our schemes rely on all frames that were encoded eventually arriving on some stream, but neither of us take a total dependency on when or which stream.
[03:40:12] <Mike Bishop / Mike Bishop> (Note that you could simultaneously send the headers and RST the data stream if you don't want the server to actually act on the request.)
[03:41:32] <Mike Bishop / Mike Bishop> Buck, to clarify -- does that mean the commit epoch is the receiver's own sequence numbers and how far it thinks has been ACK'd, or is it echoing back the sequence numbers from the other direction?
[03:41:34] <afrind> The data stream rst could be delayed, so the server might act on the request headers
[03:42:11] <Mike Bishop / Mike Bishop> Echoing them back seems cleaner; no dependency on visibility into transport logic.
[03:42:16] <Buck Krasic> No echo.
[03:42:47] <Buck Krasic> the sender simply tracks when all the sent header bytes have been acked, using the existing QUIC reliable stream machinery.  
[03:43:52] <Buck Krasic> The only extra on the wire data are the two integers sent from sender to reciever as part of headers frame.
[03:43:54] <Mike Bishop / Mike Bishop> I'd be hesitant about that.  (Remember I'm approaching this from a standpoint of an OS-owned QUIC implementation, and third-party apps.)  That's very granular information to require the HTTP layer to have access to.
[03:44:29] <Buck Krasic> you mean transport quic in OS, but http outside?
[03:45:45] <Mike Bishop / Mike Bishop> HTTP is also in OS, but it varies with the legal climate whether we're allowed to have "special access" to lower layers.
[03:46:13] <Mike Bishop / Mike Bishop> (WinInet used to ship down-level with IE updates, so we're first-party on the new OS, but semi-third-party on downlevel.)
[03:46:59] <Buck Krasic> Hmm.  I think that's an important discussion to have.  Speaking for myself, I thought a high level philosophy of QUIC was about performance gains precisely by removing layer barriers.
[03:47:41] <Mike Bishop / Mike Bishop> And that may imply that the OS QUIC needs to expose a *lot* of information to its callers, whether they're ourselves or Joe Schmo.
[03:47:55] <lucasp> I'm wondering how tied to headers this is, is it possible the dynamic-table part of QPACK just a generic dictionary compression mechanism.
[03:48:18] <Mike Bishop / Mike Bishop> But in this case, it seems like including "I've seen all HPACK frames through your sequence number 12." is equivalent, or nearly.
[03:48:28] <Buck Krasic> generic compression techniques are dangerous, e.g. due to CRIME atack.
[03:49:50] <lucasp> so the application of this to the construction of HTTP headers is a security bounding?
[03:49:54] <Mike Bishop / Mike Bishop> HPACK really is pretty generic within the realm of key=value sequence compression, though.  Rendering the headers as text and using bytestream compression is what bought us CRIME.
[03:50:49] <Mike Bishop / Mike Bishop> Yes -- using GZip for compression allowed the attacker to guess at header values one character at a time.  HPACK is somewhat less efficient, but requires an exact match to verify your guess.
[03:50:50] <Buck Krasic> I'd be all for going to true binary headers, but that's probably a huge can of worms. :)
[03:51:26] <Mike Bishop / Mike Bishop> That's precisely why QPACK says that it doesn't attempt to incorporate the other proposed improvements.  :-)
[03:51:36] <lucasp> If Indexing and reuse were useful to other application layer protocols, then perhaps this could be pushed down to transport and QPACK described dynamic table in terms of the using the transport feature
[03:51:44] <Mike Bishop / Mike Bishop> Ah, I see I'm not the only one with kids impinging on the interim.  ;-)
[03:51:52] <Buck Krasic> yep
[03:52:28] <Mike Bishop / Mike Bishop> The bug apparently made the minutes yesterday. I haven't looked to see if his remarks during my presentation were minuted.
[03:52:29] <Buck Krasic> at least they bring banana milkshakes..  
[03:52:51] <craigt> It's kind of refreshing that family life blurs into  these events
[03:52:52] <Mike Bishop / Mike Bishop> Lucky!  Mine tells me he's pulled apart his train tracks and wants me to reassemble them.  ;-)
[03:52:52] <mnot> WAT - BANANA MILKSHAKES?
[03:53:09] <Mike Bishop / Mike Bishop> But my wife brought pizza during the TLS presentation, so all is well.
[03:53:21] <craigt> i saw….and was jealous
[03:53:28] <Daniel> soon 5am here, no kids around =)
[03:53:53] <craigt> …yes…0353…the house is "quiet as a mouse"
[03:54:08] <Sean Turner> mine's asleep thank goodness :)
[03:54:13] Mirja Kuehlewind joins the room
[03:54:45] <craigt> Mike: How old, looks similar to my son…
[03:56:00] <Mike Bishop / Mike Bishop> Turned two on Friday.  The pizza is leftover from his party.  Last-minute cancellations left us with three large pizzas, half a birthday cake, and a bucket of ice cream left over.
[03:56:07] <Mike Bishop / Mike Bishop> OH NOOOO.....  ;-)
[03:57:03] <Buck Krasic> hah.  My boys are 5 and 2 1/2.
[03:58:56] <craigt> …you're a few months ahead in one aspect: I have a 15yr daughter and a 19mo son
[03:59:09] <craigt> …had a rest in the middle
[03:59:34] hardie@xmpp.rg.net joins the room
[03:59:57] <lucasp> similar to gap between http/1 and http/2 :P
[04:00:02] <Daniel> haha
[04:00:09] <Mike Bishop / Mike Bishop> LOL.
[04:01:36] <craigt> …if you're implying that i'm lining up with protocol releases….i'd better have a stern conversation with the wife in the morning
[04:01:48] <craigt> …as there's something I don't know about
[04:01:58] <Daniel> 2018, right? B)
[04:02:44] <Buck Krasic> well, QUIC is out of order, so all bets are off
[04:08:35] <craigt> Quick straw poll: Who's going to be in Chicago?
[04:08:41] <Sean Turner> me
[04:08:57] <Sean Turner> I assume you mean @ the IETF meeting?
[04:09:06] <craigt> Yes, sorry.
[04:09:11] <Sean Turner> me ;)
[04:09:12] <Mike Bishop / Mike Bishop> BTW, @mnot, I'll need to drop off WebEx around lunchtime tomorrow; I'll call in, but mostly remain muted.
[04:09:18] <Mike Bishop / Mike Bishop> Yes, I'll be at the next IETF.
[04:11:33] Brian Trammell joins the room
[04:12:11] <mnot> https://http2study.connpass.com/event/48577/
[04:12:16] <Sean Turner> yes
[04:12:17] <Daniel> yes
[04:12:17] <craigt> yes
[04:15:59] <Buck Krasic> yes, I'm back
[04:21:46] <craigt> I hate statistics like this that don't provide a second aspect: Are those 1% all from a certain device type, network type, demograph etc.
[04:22:16] <craigt> Is it 1% of all but actually 15% of radio networks?
[04:22:32] <Buck Krasic> this is across all users of chrome stable worldwide
[04:22:51] <craigt> indeed; which is sort of my point.
[04:22:56] Dirk Kutscher joins the room
[04:23:51] jo.ietf joins the room
[04:24:46] <lucasp> is this a data set that can be shared with the WG?
[04:25:04] <mnot> craig, please stay muted unless you’re talking
[04:25:14] Lars Eggert joins the room
[04:25:40] <craigt> I recently did some analysis of certain SSL functions for example: with 3 countries being high outliers.
[04:26:27] <craigt> mnot: I was going to say something but couldn't find a break...
[04:33:31] <Sean Turner> awesome
[04:39:42] Dirk Kutscher leaves the room
[04:50:00] Dirk Kutscher joins the room
[05:00:48] <mnot> Suggest: SHUT_YOUR_TALKING
[05:01:03] <hardie@xmpp.rg.net> PIE_HOLE_CLOSING
[05:02:10] <ekr> NAH_NAH_NAH_I_CANT_HEAR_YOU
[05:02:38] <craigt> a unicode palm to talk to?
[05:03:12] <hardie@xmpp.rg.net> :-#
[05:09:22] Dirk Kutscher leaves the room
[05:10:52] Dirk Kutscher joins the room
[05:12:18] <mnot> breaking until :30
[05:12:20] Dirk Kutscher leaves the room
[05:13:02] Dirk Kutscher joins the room
[05:14:09] Buck Krasic leaves the room
[05:14:39] <lucasp> mike did we need to discuss https://github.com/quicwg/base-drafts/issues/87 which was deferred this morning?
[05:15:02] <lucasp> or was it covered enough already
[05:17:10] Sean Turner leaves the room
[05:18:05] Dirk Kutscher leaves the room
[05:18:10] Lars Eggert leaves the room
[05:25:03] Lars Eggert joins the room
[05:26:08] <mnot> starting
[05:26:37] <mnot> hear us?
[05:26:41] <Daniel> yes
[05:28:20] Lars Eggert leaves the room: Disconnected: closed
[05:31:45] Dirk Kutscher joins the room
[05:38:23] Sean Turner joins the room
[05:49:47] <hardie@xmpp.rg.net> This doesn't really seem like unidirectional streams, it seems like instantiating this as paired streams, which does change the state machine but doesn't result in any fully unidirectional stream.
[05:52:08] Dirk Kutscher leaves the room
[05:52:57] <hardie@xmpp.rg.net> Warning to remote folks: there is a white board in the room, and I strongly suspect we're one cycle away from trying to get 50 people around it.
[05:59:18] <craigt> We're exploring using multicast/LTE-broadcast transmission using a quic derived protocol. Resources transferred by HTTP server push. All streams being unidirectional does make this transmission mode closer to the main spec and may allow for increased code re-use
[05:59:25] <hardie@xmpp.rg.net> Who is going to say multicast?  My bet is on Spencer.
[05:59:35] <hardie@xmpp.rg.net> Darn, craigt beat Spencer!
[05:59:38] <craigt> lol
[05:59:41] <lucasp> haha
[06:00:17] Dirk Kutscher joins the room
[06:02:59] Dirk Kutscher leaves the room
[06:05:58] Dirk Kutscher joins the room
[06:11:12] <spencerdawkins> So, I'm trying not to sound like the AD here (attempting to speak as an individual) here, but ...
One of the options we discussed before QUIC was chartered, was to do a second protocol that didn't look like HTTP, to make sure QUIC wasn't TOO optimized for HTTP/2. The second protocol I heard proposed most often was DNS.
[06:11:48] <mnot> At least a sketch of what it would look like would indeed be helpful...
[06:12:03] hardie@xmpp.rg.net leaves the room
[06:12:16] ted.h joins the room
[06:12:43] <spencerdawkins> We didn't include DNS in the charter, but I would have been OK if we had.
I'm a little concerned that what we're talking about here isn't one other application, but every kind of application that we can imagine.
I'll wait to see the pull request before I say more, but I wanted to say at least that much ;-)
[06:12:52] <craigt> indeed; I left the BOF expecting to see that in the charter…eyebrow raised subsequently…I'll admit to dropping the list  for a bit
[06:13:00] <mnot> Perhaps one of the goals we should set for ourselves is to have the documents in a shape suitable for someone from the DNS community who’s keen to write a mapping -- unless someone here is willing/able
[06:13:25] <mnot> ... in some reasonable timeframe where we can still incorporate their feedback.
[06:13:38] Dirk Kutscher leaves the room
[06:14:25] <jo.ietf> You could argue that DNS is also kind of a short request/response protocol, which could be consider pretty close to HTTP in that regard. Something with long lasting connections (and, possibly, streams) might give more diversity
[06:14:28] <ted.h> Just to ask a basic question, are you imagining that this would be stub to recursive or recursive to authoritative or both?  The optimization for the first is that you could open a multiplexed connection to your recursive and get the answers back for different queries without head of line blocking.
[06:15:19] <mnot> re: req/res -- true. Perhaps use cases like RTC would be more helpful, but that’s a big task.
[06:15:24] <ted.h> But Jo is right, this is request response.  Peer-to-peer data channel (currently sctp/dtls/udp) is more diverse and there's a bigger community playing with it.
[06:15:47] Dirk Kutscher joins the room
[06:16:38] <ted.h> Of course the DNS over HTTP boflet indicates that there might be a large community willing to look at DNS over QUIC, if we opened it up.
[06:16:57] <mnot> Heh. True.
[06:16:58] <craigt> i have certainly had a few corridor chats to that effect
[06:17:32] <jo.ietf> RTC would make sense.  We can take a look at this, with all the surrounding control channel “beauty”
[06:18:01] Dirk Kutscher leaves the room
[06:18:29] <lucasp> Pi digit generation protocol is inappropriate?
[06:18:44] <ted.h> I do think the recursive to stub would get a big uplift from the equivalent of pushed data for what's now DNS additional data.  That's limited by the current UDP packet size in common deployments, but would get much more effective use in QUIC.
[06:19:28] <ted.h> jo: data channel, media, or both?
[06:20:08] <jo.ietf> Would start with media
[06:20:35] <jo.ietf> (SDP for that is a bit easier and there is less diversity)
[06:20:41] <jo.ietf> Data could come next
[06:21:22] <ted.h> Then I think an early design decision is how you want to report RTCP like stats; if that's not return traffic on a bidirectional stream, is it coalesced into a feedback stream or is there a feedback stream per flow.
[06:22:10] <jo.ietf> Original RTP has one media + two control channels, so there is a bit of asymmetry. But then, with two senders, we get more symmetric
[06:23:00] <jo.ietf> The interesting questions is how much of these stats you could get out of the QUIC machinery
[06:23:48] Buck Krasic joins the room
[06:23:50] Dirk Kutscher joins the room
[06:24:38] <ted.h> I think you could get either the same data with lower overhead or richer data, but that is intuition, not based on a real analysis.
[06:25:38] <jo.ietf> You won’t get detailed receiver buffer stats and playout delays, so there would likely always be a complement on top
[06:25:46] <craigt> was just typing: partial reliability might be a requirement for rtp/rtcp also. Which makes it an interesting straw man to draw up
[06:26:05] Dirk Kutscher leaves the room
[06:26:15] Dirk Kutscher joins the room
[06:30:09] Dirk Kutscher leaves the room
[06:35:33] Dirk Kutscher joins the room
[06:37:48] Mirja Kuehlewind leaves the room
[06:39:53] Mirja Kuehlewind joins the room
[06:41:26] <Buck Krasic> worth pointing out that HTTP/2 declares priorities are stickly hints?  implemenation is not obligated to honor them?
[06:42:06] <mnot> that’s different -- those are hints from the client. this is about how the sender prioritises what it sends
[06:44:10] Dirk Kutscher leaves the room
[06:45:15] <Buck Krasic> if we want to open this can of worms, we might want to allow the api to specify deadlines for cancellation
[06:47:01] <craigt> Possible stupid question: How, if at all, might this relate to partial reliability?
[06:47:13] <mnot> Run away, run away?
[06:47:23] <jo.ietf> (duck and cover)
[06:48:05] <Buck Krasic> don't need it IMO, just remember that streams are super light weight.  use stream cancellation as the means of expressing partial reliability.
[06:48:24] <Buck Krasic> e.g. for media, use a stream for every media frame (ie. video frame, audio frame, etc.)
[06:48:51] <Buck Krasic> so if you want to say that a given video frame is too late, drop it by cancelling the stream.
[06:48:55] Dirk Kutscher joins the room
[06:49:59] <jo.ietf> stream cancellation appears too heavy since you have some state management for each stream; there should be something nicer (or we need to improve on stream operations)
[06:50:02] <craigt> can the sender already describe a lifetime?
[06:50:29] <jo.ietf> that would be useful (or cancel rtx)
[06:51:14] <Buck Krasic> transport state management is no problem I think, are you referring to app state management?
[06:51:36] ted.h leaves the room
[06:51:39] <jo.ietf> Referring to transport state.
[06:51:39] <spencerdawkins> I probably shouldn't ask this, but is the retransmission behavior we've been talking about appropriate for applications that might not be HTTP?
[06:51:45] ekr leaves the room
[06:52:08] <Buck Krasic> we have to support arbitrary cancellation anyway, so this adds nothing new.
[06:52:54] <craigt> spencerdawkins: …your earlier questions made me think of my last…another app definitely needs a straw man
[06:53:49] Lars Eggert joins the room
[06:57:26] Lars Eggert leaves the room: Disconnected: closed
[06:57:52] ekr joins the room
[07:00:27] Lars Eggert joins the room
[07:00:29] <craigt> Kids are up…
[07:01:25] afrind leaves the room
[07:01:28] ted.h joins the room
[07:01:34] afrind joins the room
[07:01:40] <Buck Krasic> mine only just went down...
[07:01:51] <Buck Krasic> sigh
[07:03:17] <mnot> remote folks see and hear still?
[07:03:21] <mnot> (anyone there still?)
[07:03:32] <craigt> yes, all ok
[07:03:33] <lucasp> yes to both
[07:03:42] <Sean Turner> yep
[07:03:48] <Sean Turner> fading but here
[07:07:31] Dirk Kutscher leaves the room
[07:13:20] ted.h leaves the room
[07:13:26] Sean Turner leaves the room: Replaced by new connection
[07:13:29] Sean Turner joins the room
[07:19:23] <craigt> It's a shame some of the passionate multi-path ppl aren't in the room.
[07:19:27] <craigt> Lorenzo?
[07:19:30] patrick joins the room
[07:20:19] <spencerdawkins> Honestly, I TRY to behave ...
[07:24:55] <Buck Krasic> I think part of the problem is that most of the stakeholders who want multipath badly have already implemented it at a higher level, so it will be very hard to move that down to transport.
[07:28:40] <craigt> I'm happy with the known, client controlled use case…I do wonder if the unplanned is achievable…whether it will diminish over time…etc.
[07:31:33] <ekr> There actually is a very nice solution with public key cryptography
[07:31:37] <ekr> It’s just that performance is really abd
[07:35:27] <craigt> …assuming no worse than timeout/reconnect…I wonder what the stats would be for client planned vs. path/unplanned…
[07:38:59] <Buck Krasic> reminds me of old research called trickle, that did a kind of TCP cookie for migration.
[07:39:49] <Buck Krasic> .cs.cornell.edu/~ashieh/trickles/trickles-paper/stcp.html
[07:40:30] <Buck Krasic> http://www.cs.cornell.edu/~ashieh/trickles/trickles-paper/stcp.html
[07:41:15] <Buck Krasic> jeesh 16 years ago.  I'm getting old.
[07:41:37] <Buck Krasic> http://nms.lcs.mit.edu/migrate/
[07:48:16] <ekr> What I was talking about encrypting the packet number
[07:48:18] <ekr> https://github.com/quicwg/base-drafts/issues/231
[07:53:05] Dirk Kutscher joins the room
[07:53:28] <craigt> That's certainly possible, but mobile device hueristics tend to migrate connections before the connection is totally lost
[07:55:14] <craigt> Mobility and mobile device network management/migration
[07:55:20] Dirk Kutscher leaves the room
[08:00:28] Brian Trammell leaves the room
[08:01:43] g.e.montenegro leaves the room
[08:02:20] Kaoru Maeda leaves the room
[08:02:20] patrick joins the room
[08:02:33] mnot leaves the room
[08:02:51] <Sean Turner> see you tomorrow!
[08:02:56] Sean Turner leaves the room
[08:03:07] Buck Krasic leaves the room
[08:03:31] Mirja Kuehlewind leaves the room
[08:03:31] Lars Eggert leaves the room
[08:03:43] chi.jiun.su leaves the room: offline
[08:03:58] mcmanus leaves the room
[08:04:06] <craigt> See you tonight ;)
[08:04:07] Katsushi Kobayashi leaves the room
[08:04:08] jo.ietf leaves the room
[08:04:55] Martin Thomson leaves the room
[08:04:56] spencerdawkins leaves the room
[08:05:00] craigt leaves the room: Disconnected: closed
[08:06:58] fujisaki.tomohiro leaves the room
[08:07:00] lucasp leaves the room
[08:07:36] lstewart leaves the room
[08:16:00] ekr leaves the room
[08:19:36] ranjeeth leaves the room
[08:20:20] Dirk Kutscher joins the room
[08:21:17] Dirk Kutscher leaves the room
[08:21:18] jo.ietf joins the room
[08:21:30] Dirk Kutscher joins the room
[08:22:01] afrind leaves the room
[08:22:53] jo.ietf leaves the room: Disconnected: closed
[08:23:19] jo.ietf joins the room
[08:23:50] mnot joins the room
[08:24:12] Dirk Kutscher leaves the room
[08:24:33] Dirk Kutscher joins the room
[08:25:09] jo.ietf leaves the room: Disconnected: closed
[08:26:04] mnot leaves the room
[08:27:12] dragana leaves the room: Disconnected: closed
[08:28:46] jo.ietf joins the room
[08:35:16] Katsushi Kobayashi joins the room
[08:38:57] ekr joins the room
[08:51:59] mcmanus joins the room
[09:27:09] jo.ietf leaves the room
[09:27:14] Dirk Kutscher leaves the room
[09:29:33] ekr leaves the room
[09:29:56] Katsushi Kobayashi leaves the room
[09:31:46] Dirk Kutscher joins the room
[09:43:34] patrick leaves the room
[09:50:34] Dirk Kutscher leaves the room
[09:58:00] mcmanus leaves the room
[10:11:07] Dirk Kutscher joins the room
[10:36:24] Katsushi Kobayashi joins the room
[10:37:29] Brian Trammell joins the room
[10:38:25] Brian Trammell leaves the room
[10:41:10] Dirk Kutscher leaves the room
[10:50:16] Mirja Kuehlewind joins the room
[11:01:26] Mirja Kuehlewind leaves the room
[11:17:37] Katsushi Kobayashi leaves the room
[11:18:20] Dirk Kutscher joins the room
[11:22:13] Katsushi Kobayashi joins the room
[11:26:56] Alissa Cooper joins the room
[11:27:28] Alissa Cooper leaves the room
[11:36:53] Dirk Kutscher leaves the room
[11:45:33] Dirk Kutscher joins the room
[12:07:52] Dirk Kutscher leaves the room
[12:12:52] Dirk Kutscher joins the room
[12:20:49] Katsushi Kobayashi leaves the room
[12:31:43] Dirk Kutscher leaves the room
[12:35:54] mcmanus joins the room
[12:40:06] Dirk Kutscher joins the room
[12:56:55] Dirk Kutscher leaves the room
[13:07:23] Dirk Kutscher joins the room
[13:14:58] Alissa Cooper leaves the room
[13:15:58] Katsushi Kobayashi joins the room
[13:16:58] mcmanus leaves the room
[13:26:20] jo.ietf joins the room
[13:31:18] Katsushi Kobayashi leaves the room
[13:52:53] Alissa Cooper joins the room
[14:06:55] Dirk Kutscher leaves the room
[14:07:11] patrick joins the room
[14:44:58] Alissa Cooper leaves the room
[14:47:13] patrick leaves the room
[14:49:59] jo.ietf leaves the room
[15:10:51] ranjeeth joins the room
[15:34:17] patrick leaves the room
[15:34:36] patrick joins the room
[15:57:47] ranjeeth leaves the room
[17:03:41] Daniel leaves the room
[17:22:21] patrick joins the room
[17:38:43] patrick leaves the room
[17:39:30] Daniel joins the room
[17:40:09] patrick joins the room
[17:46:51] patrick leaves the room
[17:54:17] patrick joins the room
[18:11:07] patrick joins the room
[18:47:09] patrick leaves the room
[19:53:05] ekr joins the room
[19:53:16] Martin Thomson joins the room
[19:54:37] ted.h joins the room
[19:55:15] ted.h leaves the room
[20:11:56] ekr leaves the room
[20:12:14] ekr joins the room
[20:22:36] patrick joins the room
[20:39:08] Daniel leaves the room
[20:39:25] Daniel joins the room
[21:17:28] ekr leaves the room
[21:24:56] ekr joins the room
[21:57:54] mcmanus joins the room
[22:01:22] ekr leaves the room
[22:02:25] patrick leaves the room
[22:02:53] mcmanus joins the room
[22:03:00] mcmanus leaves the room
[22:21:11] afrind joins the room
[22:23:45] jo.ietf joins the room
[22:26:08] afrind leaves the room
[22:36:53] patrick joins the room
[22:45:00] mcmanus leaves the room
[22:53:58] mcmanus joins the room
[22:54:27] Mirja Kuehlewind joins the room
[23:01:01] ekr joins the room
[23:07:01] ekr leaves the room
[23:17:43] Mirja Kuehlewind leaves the room
[23:27:31] patrick leaves the room
[23:44:13] jo.ietf leaves the room
[23:48:46] Martin Thomson leaves the room
[23:56:01] mcmanus leaves the room
[23:57:21] mnot joins the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!