IETF
QUIC
quic@jabber.ietf.org
Thursday, June 7, 2018< ^ >
Lars has set the subject to: IETF QUIC WG
Room Configuration
Room Occupants

GMT+0
[03:45:15] ekr joins the room
[04:33:57] Christian leaves the room: Disconnected: Replaced by new connection
[04:33:57] Christian joins the room
[04:35:22] afrind joins the room
[04:40:48] ekr leaves the room
[04:45:59] afrind leaves the room: Stream reset by peer
[05:58:02] ekr joins the room
[06:06:23] mnot joins the room
[06:12:52] mnot leaves the room
[06:14:28] ekr leaves the room
[06:16:35] mnot joins the room
[06:21:49] mnot leaves the room
[06:50:39] Magnus Westerlund joins the room
[06:51:59] Jari Arkko leaves the room
[06:59:54] Jari Arkko joins the room
[07:07:36] gryning joins the room
[07:08:31] Martin Thomson joins the room
[07:09:30] Sean Turner joins the room
[07:14:04] afrind joins the room
[07:15:53] <Roberto> Shista?
[07:17:04] ekr joins the room
[07:17:50] mnot joins the room
[07:23:29] Jari Arkko leaves the room
[07:28:03] ihlar joins the room
[07:28:49] <Christian> +1 for 4pm
[07:30:30] masaori@xmpp.jp joins the room
[07:30:43] chi.jiun.su joins the room
[07:31:27] Jari Arkko joins the room
[07:34:55] <Sean Turner> mnutes: https://docs.google.com/document/d/1-2aBorKh9WVE3jM5mBlYNliJH0Ef_gp3dJo0RBe9y4c/edit#
[07:35:02] brian@trammell.ch joins the room
[07:35:07] Lars Eggert joins the room
[07:35:10] g.e.montenegro joins the room
[07:35:17] dtikhonov joins the room
[07:37:09] <Roberto> It has me laughing, actually πŸ™‚
[07:37:54] mnot joins the room
[07:40:19] subodh joins the room
[07:43:16] mnot leaves the room
[07:44:37] <Sean Turner> how's the sound out there?
[07:45:02] gryning is now known as craigt
[07:45:03] <ekr> silent
[07:45:23] Lars Eggert leaves the room
[07:45:49] <Roberto> *raise hand*
[07:45:57] <mnot> ack
[07:46:38] mnot joins the room
[07:52:00] mnot leaves the room
[07:53:56] lucaspardue joins the room
[07:54:00] <Roberto> ECN is an optimization. At worse the endpoint needs to notice and prevent congestive collapse.
[07:54:09] <Roberto> Are you worried about something else Christian?
[07:55:37] spencerdawkins joins the room
[07:56:26] <Christian> Yes. My main problem is that ECN is not an "honest signal", contrary to delay and losses. Both the network and the endpoints can play games of "adversarial marking" or "adversarial reporting"
[07:57:46] Gorry Fairhurst joins the room
[07:58:01] <Christian> Also, ECN is outside the encryption envelope, opening vulnerabilities for replay attacks, man on the side, etc.
[07:58:31] <Gorry Fairhurst> If you cheat the ECN markings ... and try to use more capacity ... you will likely induce congestion and then create loss or delay - you will then suffer as a penalty (it doesn't pay to cheat on the marks).
[07:59:08] <Christian> Well, there are adversaries who want to induce congestion...
[08:00:12] <Gorry Fairhurst> I wonder, are those attackers unable to induce loss? (which would be much less hard to hide and have more immediate effect on the flow).
[08:01:11] <Roberto> Given that we don't have mechanisms to establish a trust chain for routing devices on the network, it seems like the ECN problem (marking, not marking, bleacking, etc). isn't really a solvable one
[08:01:33] <Christian> Roberto: yes.
[08:02:24] <brian@trammell.ch> spencer: mute?
[08:02:46] ekr leaves the room
[08:04:39] <Gorry Fairhurst> But I think this is not a proper view of the operation! - In the limit: I see the ECN information as an advisory input to the congestion controller β€” something that can help you avoid overshoot of the buffer. If the transport wishes, it can make a decision to later disable ECN when it thinks it is under attack (although I have not yet seen a case where you would do that). None of this impacts the ability of the transport to send packets, it just impacts decisions within the CC.
[08:04:40] Lars Eggert joins the room
[08:06:01] ekr joins the room
[08:06:06] <spencerdawkins> Gorry, does the experimental part of ECN apply here?
[08:06:10] <Roberto> *raise hand*
[08:06:40] <mnot> ack
[08:07:11] <Martin Thomson> Christian, you should raise an issue for that suggestion.
[08:07:26] <Christian> ack
[08:07:39] <Martin Thomson> it's a good one, I think
[08:07:40] <Gorry Fairhurst> In response to Christian: yes, I think the sender should be allowed to set CE and check the receiver response - this has been discussed in TSVWG before  β€” it is not something unique to QUIC.
[08:08:03] <Roberto> *lowers hand* πŸ˜‰
[08:08:05] <Martin Thomson> the sender knows that it has CE marked packets, and can watch for that packet being acknowledged, not attribute that marking to congestion
[08:08:31] <Roberto> It was covered in conversation. No need to talk about it more.
[08:08:57] <Gorry Fairhurst> Yes - sure that is what I understand. It's something I routinely do in ECN measurement work and we have talked about adding this to TCP - once we have accurate ECN feedback provided.
[08:09:28] <Roberto> That can mask actualy ECN signaling, but it can at least see that the route doesn't reliably bleach.
[08:09:35] <Roberto> *actual
[08:09:51] <brian@trammell.ch> (Slightly on topic: systemd merged a configuration change last week that sets tcp_ecn = 1 on system boot, so Linux will start to join iOS in ECN-by-default for TCP)
[08:10:20] <mnot> Huh; that means my boxes will do it next time I pacmac -Syu
[08:10:43] <Gorry Fairhurst> Sure - a sender should not set CE often, but as a probe I think it has useful properties… If it masks one CE mark every now and again, it's not a big deal.
[08:11:21] mnot joins the room
[08:15:44] <Christian> Issue #1426
[08:16:42] mnot leaves the room
[08:20:28] mnot joins the room
[08:22:30] <Christian> What are we trying to achieve in the case of very low latency links?
[08:22:53] <Christian> Is this about trying to reduce buffer requirements in data center switches?
[08:25:24] <Christian> Using sRTT introduces a bad feedback loop. In case of congestion sRTT becomes larger and the feedback becomes less frequent
[08:25:45] <Christian> *raise hand*
[08:25:51] mnot leaves the room
[08:27:35] <Christian> What Ian said. Using minRTT instead of sRTT is better, because it does not have the feedback loop.
[08:31:04] <Christian> Shouldn't ack frequency be treated as its own issue, separate from ECN?
[08:33:48] mnot joins the room
[08:39:10] mnot leaves the room
[08:42:52] subodh leaves the room: Stream reset by peer
[08:43:08] subodh joins the room
[08:45:54] <Roberto> For the mic: I think this is a case where the correct behavior isn't actually obvious. Seems like we should warn implementers that duplication can happen. Look out for it.
[08:46:13] mnot joins the room
[08:48:02] <Roberto> Observation: This seems better than the UDP deployability numbers which matter more to QUIC. Is this a big enough issue to care relative to the UDP dependability/deployability?
[08:48:03] janaiyengar joins the room
[08:49:50] <Roberto> i.e. if you just "mandate" ECN, and some get blackholed, won't happy-eyeballs cover us?
[08:50:08] <janaiyengar> That's the simplest proposal here
[08:50:20] <janaiyengar> "Let handshake go into protocol fallback"
[08:50:24] <Roberto> ya
[08:50:29] <Roberto> ok
[08:50:41] <janaiyengar> that works
[08:50:51] <Roberto> I'd trust that as compared to any more complex behavior that could otherwise cause issues.
[08:51:34] mnot leaves the room
[08:51:37] <Roberto> *raise hand*
[08:51:40] <Roberto> lol
[08:52:01] <Gorry Fairhurst> +1 on a simple fallback method, until we know we really need more.
[08:53:31] <janaiyengar> "No QUIC for you!"
[08:53:37] <Roberto> yup
[08:53:44] mnot leaves the room: Disconnected: closed
[08:53:56] mnot joins the room
[08:55:09] ted.h joins the room
[08:56:08] <Roberto> I'll reiterate a different way: If we believe ECN has positive benefit, then it is reasonable to tie the use of QUIC to the non-blackholing of ECN on the path. This is simple, and advances the proper thing.
[08:59:21] <spencerdawkins> and "don't get QUIC" means that, at least for HTTP over QUIC, you get HTTP over TCP, so what the user sees is not a complete fail, right?
[08:59:54] <Roberto> correcty
[09:00:00] <Roberto> *correct.
[09:00:26] <spencerdawkins> that sounds way better than most of the "blackholing" situations I've seen with other protocols!
[09:01:22] <Roberto> yup
[09:01:26] <spencerdawkins> (we kept talking for 5 minutes into the 15 minute break - are we still back at 10 after the hour?)
[09:01:35] <mnot> Yes :)
[09:01:49] craigt leaves the room: Disconnected: closed
[09:01:49] ihlar leaves the room
[09:01:51] brian@trammell.ch leaves the room: Disconnected: closed
[09:01:51] brian@trammell.ch joins the room
[09:01:55] ihlar joins the room
[09:01:56] janaiyengar leaves the room: Stream reset by peer
[09:02:34] brian@trammell.ch leaves the room: Disconnected: closed
[09:02:37] brian@trammell.ch joins the room
[09:02:59] Jari Arkko leaves the room
[09:03:05] Martin Thomson leaves the room
[09:03:12] ihlar leaves the room
[09:03:21] brian@trammell.ch leaves the room
[09:03:23] brian@trammell.ch joins the room
[09:04:07] brian@trammell.ch leaves the room: Disconnected: closed
[09:04:14] ekr leaves the room
[09:06:39] Jari Arkko joins the room
[09:08:32] Lars Eggert leaves the room
[09:09:15] Lars Eggert joins the room
[09:10:10] Martin Thomson joins the room
[09:10:52] gryning joins the room
[09:11:38] brian@trammell.ch joins the room
[09:11:50] subodh leaves the room: Stream reset by peer
[09:11:59] subodh joins the room
[09:12:36] ekr joins the room
[09:13:50] <chi.jiun.su> no sound at remote
[09:14:11] <gryning> working on it
[09:14:15] gryning is now known as craigt
[09:15:05] <craigt> Can you hear us?
[09:15:11] <chi.jiun.su> no
[09:15:23] <Roberto> the webex app itself believes that mic is muted.
[09:15:40] <Roberto> works now
[09:15:41] <chi.jiun.su> yes
[09:16:32] <dtikhonov> Who's the presenter?
[09:16:38] <ekr> Subodh Iyengar
[09:16:41] <dtikhonov> Ah
[09:16:44] <dtikhonov> merci
[09:21:08] janaiyengar joins the room
[09:21:41] <dtikhonov> RPS=?
[09:21:49] <mnot> Requests per second
[09:21:50] <dtikhonov> req per sec?
[09:21:58] dtikhonov nods -- thank you
[09:32:24] <Roberto> an *implicit* idle timeout is an impossible to optimize heartbeat-generator
[09:32:52] <Roberto> an *explicit* idle timeout allows for reasonable application behavior.
[09:33:22] <janaiyengar> it's explicit and in transport params
[09:33:28] <ted.h> Is not wanting to wake the radio the same issue here?  Don't we drop to 0RTT resumption in the longer cases of this?
[09:33:45] <Roberto> connection resumption != session resumption, sadly.
[09:34:29] <ted.h> Yeah, but radio schedulers tend to be smarter than that, so that they bundle the marked flow traffic when the radios are awake.
[09:34:57] <janaiyengar> Re explicit idle timeout: it's just something that the transport sets… and the periodic PINGs is triggered by the app, so they need to agree that the PING timeout should be shorter than the idle timeout
[09:34:58] <Roberto> I think we're talking past each other.
[09:35:03] <Roberto> Yes, the radio does smartish things.
[09:35:15] <Roberto> But, the long-polling thingie typically is a notification or similar channel.
[09:35:31] <Roberto> .. and timing out the requests that were associated with the connection via idle timeout
[09:35:45] <Roberto> .. requires the re-establishment of all of those notification channels via requests.
[09:35:52] <Roberto> (more requests)
[09:36:06] <Roberto> @jana: I think this is as much an implementation issue as a protocol issue.
[09:36:47] <lucaspardue> are FB advertsing thi h1q with Alt-Svc, and then negotiating it with ALPN?
[09:37:13] <Roberto> I think that 'idle timeout'
[09:37:19] <Roberto> is really heartbeat time πŸ™‚
[09:37:47] <Roberto> And if we treated it that way, then we could fail to send or have received ping, but still have the session working/up.
[09:38:28] <Roberto> Knowing the connection is alive should be different from knowing it must not be alive.
[09:38:30] <ted.h> Roberto.  I agree that we're talking past each other, but the conversation in the room has moved on, so we should take it to offline conversation/the list.
[09:39:07] <Roberto> *raises hand*
[09:41:11] mnot joins the room
[09:42:41] <Roberto> @Ted Is the thing you're talking about separate (after the discussion)?
[09:42:49] <Roberto> i.e. is it another issue?
[09:46:24] mnot leaves the room
[09:49:29] Jari Arkko leaves the room
[09:49:49] <ted.h> @Roberto I think the description of "waking the radio" and battery usage made presumptions about how available packets to send and data channel availability worked.  I think the behavior is a bit more complicated, but describing the interaction (both with IDLE and other elements) is probably a separable discussion.  There are some interactions, of course.
[09:50:11] <Roberto> @Ted Gotcha.
[09:51:32] Jari Arkko joins the room
[09:52:27] mnot joins the room
[09:54:24] afrind leaves the room: Stream reset by peer
[09:57:47] mnot leaves the room
[09:59:01] <Christian> reasonable priced hotel in NYC?
[09:59:42] <Christian> Hawaii in January would be nice!
[09:59:45] <ted.h> @Christian "Subway distance" could mean many things….
[10:00:10] <Christian> I get that. The Bronx is at subway distance from manhattan...
[10:01:06] <Christian> *raise hand*
[10:01:18] mnot joins the room
[10:05:20] <Christian> Yes on Mark's plan. I am willing to try stream-0 in Montreal. We want to learn asap what is wrong in draft-13
[10:06:12] Lars Eggert leaves the room
[10:06:39] mnot leaves the room
[10:06:39] <ted.h> I just want to point out that this schedule slip effects all those queued potential non-HTTP use cases we mentioned yesterday
[10:08:10] ihlar joins the room
[10:11:17] Lars Eggert joins the room
[10:12:18] mnot joins the room
[10:14:29] <dtikhonov> MIC: QPACK seems almost done
[10:15:35] Magnus Westerlund leaves the room
[10:15:53] ekr leaves the room
[10:15:53] mnot leaves the room: Disconnected: closed
[10:15:55] Lars Eggert leaves the room
[10:15:57] janaiyengar leaves the room: Stream reset by peer
[10:16:39] lucaspardue leaves the room
[10:16:42] brian@trammell.ch leaves the room
[10:17:39] mnot leaves the room
[10:17:49] ted.h leaves the room
[10:18:02] dtikhonov leaves the room
[10:18:26] Martin Thomson leaves the room
[10:20:30] Jari Arkko leaves the room
[10:33:06] subodh leaves the room: Connection failed: connection closed
[10:33:18] ihlar leaves the room
[10:33:36] g.e.montenegro leaves the room
[10:34:04] craigt leaves the room: Disconnected: closed
[10:38:23] g.e.montenegro joins the room
[10:46:49] Sean Turner leaves the room: Replaced by new connection
[10:46:51] Sean Turner joins the room
[10:50:30] Gorry Fairhurst leaves the room
[10:58:35] Sean Turner leaves the room
[11:09:54] g.e.montenegro leaves the room
[11:11:06] Jari Arkko joins the room
[11:11:30] dtikhonov joins the room
[11:11:35] dtikhonov leaves the room
[11:15:52] Lars Eggert joins the room
[11:18:23] gryning joins the room
[11:18:55] gryning is now known as craigt
[11:19:13] ekr joins the room
[11:21:04] Sean Turner joins the room
[11:23:44] lucaspardue joins the room
[11:24:07] Martin Thomson joins the room
[11:24:39] g.e.montenegro joins the room
[11:26:54] ihlar joins the room
[11:28:01] mnot joins the room
[11:28:10] <mnot> Remote audio OK?
[11:28:27] ekr leaves the room
[11:29:17] <Roberto> ya
[11:36:49] ekr joins the room
[11:38:20] <Roberto> For large deployments, the scheme that is spoken about here requires some interesting coordination between the entities which are giving out the CIDs to the servers.
[11:39:31] <Roberto> This works with multipath as well, as long as the server gets multiple CIDs.
[11:39:50] <Roberto> Coordination because if you have a large number of servers, then the number of connections will also be large.
[11:39:55] <Roberto> YOu need to partition the space across them.
[11:41:10] brian@trammell.ch joins the room
[11:41:35] <Roberto> It is an allocation interface, moreso than a management interface
[11:42:01] <Martin Thomson> aww, I wanted to say it, because we need more people saying that sort of thing
[11:42:07] <Roberto> heh
[11:42:38] <Roberto> The lb doesnt' have to know them. I has to encode them.
[11:43:30] janaiyengar joins the room
[11:45:41] <Christian> A secret shared with all servers hosted by AWS?
[11:46:04] <Roberto> Only if they wanted to. They could share on a per service basis, or hostname, or 5-tuple, etc.
[11:46:11] <Roberto> Partitioning is a separate problem.. har har?
[11:46:29] <janaiyengar> You can keep the secret on GoogleCDN, it'll be available to all AWS servers
[11:46:38] <Roberto> AWS would probably want to fake it anyway with ipv6.
[11:46:42] <ekr> put it on twitter
[11:46:42] <Roberto> rofl
[11:46:45] Sean Turner leaves the room
[11:47:04] <mnot> Just mark the account private... what?
[11:48:46] <Christian> The more I hear these talks of shared secret, the sooner I believe they will reinvent Kerberos...
[11:49:04] <Roberto> Isn't everything a shared secret? πŸ™‚
[11:49:19] <ekr> Those who do not remember kerberos are doomed to repeat it
[11:49:21] <janaiyengar> some are more shared than others
[11:49:39] <janaiyengar> just ask ekr's co-AD
[11:49:47] <Roberto> The basic thing is really: Do you share an algorithm and something that makes it work, or do you share individual datums.
[11:50:02] <janaiyengar> yup
[11:50:05] <Roberto> The latter will have latency issues.
[11:50:11] <Roberto> The former has security issues.
[11:51:03] Sean Turner joins the room
[11:51:27] <Roberto> Protocol, Mark, Protocol!
[11:51:29] <Roberto> πŸ˜‰
[11:51:45] <mnot> You *are* using something called Jabber to say that...
[11:52:05] <Roberto> Turtles. Its turtles all the way down.
[11:52:11] <mnot> yup.
[11:53:40] <Christian> Turtles with shared secrets written on the shell
[11:53:53] <Roberto> Aren't the turtles the secret?
[11:54:20] <Roberto> Secrets on secrets on secrets...
[11:54:48] <Roberto> Yup. Have seen it.
[11:56:56] <Roberto> wow
[11:57:14] <Christian> * raise hand *
[11:57:21] <mnot> Ack
[12:07:18] Sean Turner leaves the room
[12:07:28] Sean Turner joins the room
[12:10:08] ekr leaves the room
[12:11:02] ekr joins the room
[12:12:59] dtikhonov joins the room
[12:13:28] Magnus Westerlund joins the room
[12:14:27] <Roberto> 4hz of dog.
[12:14:36] <Roberto> 4hz of spinning dog.
[12:15:11] <Roberto> -1 ignore the flags πŸ˜‰
[12:15:39] <brian@trammell.ch> 4 is a good number for quic as we discovered earlier today
[12:16:17] <dtikhonov> MIC: you still have to track -- either opened streams or closed streams.  There was an email exchange about that some weeks earlier.
[12:16:27] <mnot> ack
[12:16:49] <dtikhonov> (that's as regards "more code"-- same amount of code, IMO)
[12:18:35] <dtikhonov> MIC: What's the purpose of this -- why would server send responses on implicitly opnede streams before it knows what the requests are?
[12:18:43] <mnot> ack
[12:18:46] <Roberto> non http
[12:19:56] <Roberto> video: imagine frame per stream. Server will appear to send many streams. You really don't want a request per frame.
[12:20:01] dtikhonov nods vigorosly: Dmitri is a NO
[12:20:23] <dtikhonov> Well frankly I haven't considered video (not familiar)
[12:20:25] Martin Thomson leaves the room
[12:20:30] <Roberto> *raise hand*
[12:20:35] <mnot> ack
[12:24:19] <Roberto> does implicit open require monotonic (by 1s / 4s) stream numbering?
[12:27:15] <g.e.montenegro> From Nick (who's not on jabber): I'm for Implicit Open, if they vote.
I also like the symmetry of streams opening in the same order on both sides
even if there is packet loss/reordering
[12:28:39] <Roberto> for the mic:  it seems that implicit open requires monotonic (by 1s / 4s) stream numbering due to max-streams
[12:29:15] <Roberto> I send stream 100.
[12:29:24] <Roberto> How many streams are open?
[12:30:03] <Roberto> If it is 100/4, then we're allocating streams by 4s.
[12:30:24] <janaiyengar> yes, but the limit is applied as #streams
[12:30:29] <Roberto> yup
[12:31:07] <Roberto> Just saying that this (implicit open) implies something about which streams < k are open when k is mentioned.
[12:31:14] <Roberto> Yes. that is why I was saying 1/4s πŸ™‚
[12:31:58] <Roberto> Yes-- what Martin said.
[12:32:52] Martin Thomson joins the room
[12:32:53] <Roberto> Implicit open seems less chatty.
[12:33:05] <Roberto> On that basis only it seems preferable.
[12:33:48] <Christian> I like implicit, and I can use MAX STREAM to control the openings
[12:33:51] <Roberto> Can't live with chatty stuff.
[12:33:54] <Roberto> implicit yes.
[12:33:58] <Roberto> explicit no.
[12:34:05] <Christian> * hum for implicit *
[12:34:32] <dtikhonov> I am fine with consensus
[12:35:18] <Roberto> An extension framework for the extension frame...
[12:36:32] spencerdawkins leaves the room
[12:36:37] <Roberto> I vote for Martin picks something.
[12:43:00] <Christian> There are two problems, support in the parser and agreement to use it in a specific connection. For the parser, the varint is the best. Unique number identifies a syntax, points to marshalling routines, etc. For the semantics, you want negotiation that yes i will do that, and transport parameters is the most adequate.
[12:43:50] <Christian> * raise hand *
[12:44:03] <mnot> ack
[12:44:43] Martin Thomson leaves the room
[12:45:21] <ekr> Huitema: I agree that we should decide whether things are permitted via TP
[12:45:48] <Roberto> We're spending an inordinate amount of time on this, and we're going to rev the protocol soon anyway. Does the marginal efficiency, so long as it isn't grossly inefficient, really matter?
[12:45:59] <Roberto> Ya, #1
[12:46:00] <brian@trammell.ch> +1, TP is the right mechanism here
[12:46:35] <brian@trammell.ch> Roberto: there is a question as to whether some of the stuff we want to do in "quicv2" might be extensions to v1, with the same wire image version.
[12:46:38] <brian@trammell.ch> but yeah.
[12:47:05] <Roberto> Then 'promoting' the extension to something more efficient is the v2.
[12:47:15] <brian@trammell.ch> ok i buy that
[12:47:19] <Roberto> 'cause many of the other things I'd love to see won't be efficiently done in the wire format we have now.
[12:47:19] Martin Thomson joins the room
[12:47:39] <brian@trammell.ch> (Another alternative is we do nothing, and bind a set of frame types to version.)
[12:47:44] <Roberto> ya
[12:47:53] <Roberto> I'm really just at the point of 'pick one'.
[12:48:04] <brian@trammell.ch> getting there
[12:48:52] <Martin Thomson> I've been there for a LONG time already
[12:49:03] <brian@trammell.ch> mt: if "let martin pick one
[12:49:11] <brian@trammell.ch> is the answer", what's the pick?
[12:49:46] <Roberto> I'd like to see a stated principle that extensions in v1 may look like the way extensions are done in v2.
[12:49:49] <Roberto> πŸ™‚
[12:49:56] <Roberto> *may not
[12:50:15] <dtikhonov> How about we invert it: "here is the mapping of frames that I will send" instead of "here is a mapping of frames that I process"
[12:50:23] spencerdawkins joins the room
[12:50:28] <Christian> Pick all. Special frame type zero, followed by a varint, negotitiated in the TP, with an option to remap to an 8 bit value
[12:50:28] <janaiyengar> @roberto: extensions are not invariant
[12:50:33] <janaiyengar> *not in the set fo invariants
[12:50:46] <janaiyengar> *presumably
[12:51:04] <Roberto> Saying it and having people know it.. not the same πŸ™‚
[12:51:11] <janaiyengar> fair enough
[12:51:11] <mnot> :)
[12:54:23] <Roberto> *raise hand*
[12:54:58] <Roberto> I don't get the cake anyway.
[12:57:19] <Roberto> You still need to decide if the frames have their own size.
[12:57:22] <Christian> +1 on the simple solution that MT outlined
[12:58:15] <Roberto> Two separable things: How to frame the frames, and how to interpret the frames.
[12:58:33] <Christian> +1 to varint as well
[12:59:14] <janaiyengar> @roberto: I'
[12:59:31] ihlar leaves the room
[12:59:36] <janaiyengar> d say the two separable things are: what extension you're negotiating, and what frames are needed to support it
[12:59:55] <Roberto> to be clear: I'm seriously up for anything.
[13:00:12] <janaiyengar> the first thing needs to be negotiated it, and the second thing is known if the first is known
[13:00:20] <Roberto> I was thinking: Do I have to understand all the frames and all of the things that the TP may implicitly define.
[13:00:42] <Roberto> If so, fine. Don't understand the TP, then don't allow connection.
[13:00:43] Martin Thomson leaves the room
[13:00:48] ekr leaves the room
[13:00:55] janaiyengar leaves the room: Stream reset by peer
[13:01:07] brian@trammell.ch leaves the room: Disconnected: closed
[13:01:10] nibanks joins the room
[13:01:37] ihlar joins the room
[13:01:47] masaori@xmpp.jp leaves the room
[13:02:19] nibanks joins the room
[13:02:36] nibanks leaves the room
[13:02:43] ihlar leaves the room
[13:04:07] nibanks leaves the room: Connection failed: connection closed
[13:08:07] <spencerdawkins> So, why ISN'T there a MIME encoding for dessert? That plus reliable multicast transport would come in really handy right about now.
[13:13:46] <Roberto> lol
[13:14:33] <Christian> At a minimum, we could have smello vision
[13:14:50] <Roberto> I remember smell-o-vision πŸ™‚
[13:15:03] <Roberto> But I'd rather have cake
[13:15:03] <Roberto> πŸ™‚
[13:17:31] craigt leaves the room: Disconnected: closed
[13:18:16] <Roberto> So, I can't hear anything specific that you've been saying
[13:18:39] gryning joins the room
[13:19:51] ekr joins the room
[13:19:55] Martin Thomson joins the room
[13:20:09] <Roberto> To be known in the future as non-issues?
[13:20:26] brian@trammell.ch joins the room
[13:20:57] Sean Turner leaves the room
[13:22:33] janaiyengar joins the room
[13:22:39] subodh joins the room
[13:23:10] gryning is now known as craigt
[13:26:19] ihlar joins the room
[13:26:29] <Roberto> looks good to me
[13:27:02] Sean Turner joins the room
[13:27:16] <janaiyengar> @roberto: Sorry didn't see that message earlier. Yes, my thinking as well is that all frames are expected to be understood once a TP is negotiated
[13:27:33] <janaiyengar> That's basically the TCP model of feature negotiation
[13:27:40] <Roberto> πŸ‘
[13:27:57] subodh leaves the room: Stream reset by peer
[13:28:25] <Roberto> That'll make life interesting for proxies, but I'm happy to have any resolution.
[13:28:56] <janaiyengar> TPs are in the clear
[13:29:15] <janaiyengar> though yeah, if a proxy doesn't understand a TP, it'll be interesting
[13:29:28] <Roberto> The proxy has to understand all frames (for framing, their sizes) in order to forward 'em.
[13:29:42] <Christian> Isn't server TP an encrypted extension?
[13:29:44] <Roberto> That is only the case where the extensions are not self-describing (size)
[13:29:58] <Roberto> This is a non-issue for p2p stuff.
[13:30:04] <Roberto> (e.g. tcp/tls negotiations)
[13:30:41] <Roberto> NP-NP. hehe
[13:30:51] <janaiyengar> @christian: Ah, yes.
[13:31:48] <Roberto> #1296 - meh
[13:31:48] <Christian> And in fact, having that kind of info in the clear is a bad idea. It provides a nice signature of the implementation, maybe of user prefrences
[13:33:45] <Roberto> *raise hand*
[13:34:01] <mnot> ack
[13:39:12] <ekr> BTW, I think TP actually can be used to negotiate the 0-RTT one
[13:39:17] <ekr> because you could memorize it
[13:39:33] <Roberto> state-y but cute
[13:41:09] <ekr> I would say that I think that this needs to be agreed to by both sides
[13:41:20] <Roberto> hech yes
[13:50:08] <Roberto> Now discussing motivation for the discussion about process.
[13:50:19] <Roberto> Would rather sleep.
[13:50:31] <Christian> Just kill it, OK?
[13:50:55] <janaiyengar> @christian: I think ekr's solution is an elegant way to do exactly that
[13:51:01] <Roberto> yes
[13:54:28] janaiyengar has set the subject to: Draining
[13:54:33] <Roberto> lol
[13:55:07] brian@trammell.ch leaves the room
[13:56:30] ekr leaves the room
[14:00:32] <Roberto> raise hand
[14:00:37] ekr joins the room
[14:00:44] <mnot> Ack
[14:03:58] janaiyengar has set the subject to: Really Draining
[14:03:58] ekr leaves the room
[14:04:12] Lars Eggert leaves the room
[14:04:12] <dtikhonov> bye all
[14:04:17] g.e.montenegro leaves the room
[14:04:19] chi.jiun.su leaves the room: offline
[14:04:19] <Roberto> bye folks!
[14:04:22] dtikhonov leaves the room
[14:04:25] <janaiyengar> bye folks!
[14:04:30] Christian leaves the room
[14:04:35] janaiyengar leaves the room
[14:05:00] Jari Arkko leaves the room
[14:05:02] ihlar leaves the room
[14:05:35] Martin Thomson leaves the room
[14:05:42] Roberto leaves the room: Disconnected: closed
[14:06:19] Magnus Westerlund leaves the room
[14:06:54] mnot leaves the room
[14:07:50] craigt leaves the room
[14:08:01] spencerdawkins leaves the room
[14:11:50] Sean Turner leaves the room
[14:22:41] lucaspardue leaves the room
[14:26:26] lucaspardue joins the room
[14:27:19] lucaspardue leaves the room
[14:46:07] ihlar joins the room
[14:48:22] ihlar leaves the room
[14:58:04] mnot joins the room
[15:00:06] ekr joins the room
[15:06:29] mnot leaves the room
[15:09:22] mnot joins the room
[15:09:42] mnot leaves the room
[15:14:13] ekr leaves the room
[16:01:15] Sean Turner joins the room
[16:01:49] Sean Turner leaves the room
[16:11:48] ekr joins the room
[16:17:15] ekr leaves the room
[16:20:00] lucaspardue joins the room
[16:25:14] ekr joins the room
[16:34:22] Gorry Fairhurst joins the room
[17:33:42] lucaspardue leaves the room
[17:44:31] Gorry Fairhurst leaves the room
[17:44:38] Gorry Fairhurst joins the room
[17:48:31] Gorry Fairhurst leaves the room
[17:50:15] lucaspardue joins the room
[17:53:45] Gorry Fairhurst joins the room
[18:24:22] lucaspardue leaves the room
[18:37:32] Gorry Fairhurst leaves the room
[18:46:23] Gorry Fairhurst joins the room
[18:47:01] Gorry Fairhurst leaves the room
[18:52:30] ekr leaves the room
[19:35:08] lucaspardue joins the room
[19:43:21] ekr joins the room
[20:01:51] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:01:51] lucaspardue joins the room
[20:04:46] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:04:50] lucaspardue joins the room
[20:06:03] mnot joins the room
[20:06:18] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:06:22] lucaspardue joins the room
[20:07:34] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:07:38] lucaspardue joins the room
[20:09:28] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:09:41] lucaspardue joins the room
[20:11:21] mnot leaves the room
[20:14:55] mnot joins the room
[20:15:33] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:15:38] lucaspardue joins the room
[20:17:43] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:17:47] lucaspardue joins the room
[20:18:24] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:18:29] lucaspardue joins the room
[20:20:16] mnot leaves the room
[20:21:31] ekr leaves the room
[20:22:34] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:22:37] lucaspardue joins the room
[20:32:52] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:36:40] lucaspardue joins the room
[20:38:56] lucaspardue leaves the room: Disconnected: Replaced by new connection
[20:39:33] lucaspardue joins the room
[20:43:39] lucaspardue leaves the room: Disconnected: closed
[20:50:47] Gorry Fairhurst joins the room
[21:04:49] Martin Thomson joins the room
[21:16:05] lucaspardue joins the room
[21:17:37] lucaspardue leaves the room: Disconnected: Replaced by new connection
[21:17:51] lucaspardue joins the room
[21:19:03] lucaspardue leaves the room: Disconnected: Replaced by new connection
[21:19:11] lucaspardue joins the room
[21:19:55] lucaspardue leaves the room: Disconnected: Replaced by new connection
[21:19:59] lucaspardue joins the room
[21:22:48] ekr joins the room
[21:31:59] Martin Thomson leaves the room
[21:34:11] ekr leaves the room
[21:38:56] lucaspardue leaves the room: Disconnected: closed
[21:47:31] Gorry Fairhurst leaves the room
[23:07:43] lucaspardue joins the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!