13:50-15:50 Tuesday Afternoon session I, Thai Chitlada 1 - in other time zones
unlikely to meet the nov deadline
2 tables full of implementors; around 10 implementations
getting back to basic interoperation after stream 0 changes
very few stacks dealing with key updates or migration - concerning wrt timeline
prg hopes for -17 interop.. or maybe interim in tokyo
hq is also not real well exercised
christian: concerned about lack of migration implementation. at which point do we cut features?
mnot: we are moving beyond interop talk
ekr: things that are hard to test do not get tested even if implemented. e.g. recovery. we need a test harness w automation
jana: the matrix does not contain the full feature set of quic. not ready to discuss what to cut
lars: +1 to ekr's comment. perhaps something like packetdrill
ekr: wants to prioritize harness and seeks people of similar pov
jana: what about the suite that showed up in LHR.
lars: that was more of a conformance test.. quic-tracker (?)
colin: wrt first octet discussions and avtcore.
mt: we have slides on that later
ekr: would like 4 weeks before freeze
mt: fair. point still stands that you have been warned about oncoming freeze
mnot: wg has expressed that we need a period of stability to let impls catch up
mt: outright bugs will continue to get fixed. but soon a stable protocol will need to set in. suggests a speculative issue for improvements will be more aggressively closed - this does not exclude bugs. discussing on list before opening issues will become better. editorial issues are always welcome with PR
mt: we lack experience in deployment, and we need that before rfc. therefore get that soon. might mean there are some aesthetic things that suck
(Long Header Slide 4)
ekr: probably need 1 more bit for type
david s: extensibility argues for more type bits.
ekr: 8bit pn is plausible
lenox: is this part of this version?
mt: this is not invariant (other than 1st bit) wrt next versions
colin: this avoid collisions with stun and (mumble) - please coordinate with avtcore. can we get stun demux as an invariant
mt: new requirement!
jana: is that so we don't need to continually re-argue?
colin: easier to have an invariant
jana: invariants are things that we are choosing to keep fixed as a minimal set.. stun could be one of those
colin: likely to be extremely important. basically just adding 1 additional bit of invariant
ekr: opposes. most quic don't have to be demuxed w stun. endpoints need to be able to demux, but middleboxes are more concerned about invariants
colin: expects p2p will need infra to allow this to move through
ekr: don't talk about it
jana: people who are going to do this understand it
ekr: this isn't something we have taken on
jana: we are not in the business of telling apps what they should not do.
ekr: if document has force it should not do things that are not advisable and this is not advisable
jana: import to say why not what
martin: people are already doing this.. quic/ws reference
spencer as AD: partial reliability is explicitly out of scope. we should talk
ian: its fine to say nothing given spencer's comment. however this totally works fine!
mirja: ekr please add your arguments to the github issue
lars: quic v2 will likely contain partial reliability. ops shouldn't presuppose this
mirija: just documenting current practice
jana: not clear what partial reliability is without a definition.. hard to do given its not in charter scope. stay out of the way
tommy: don't mention the PR hack. precedent to include the whole list of whacky stuff that's possible? otoh error cases are important
mirja: should we give more guidance on interface on cancelling stream?
tommy: talking about strategies is useful. agrees to do a pull request
harald: disappointed in wg discussion. the choice is whether or not we want to provide a forum for discussion of this topic or not (and yield influence if not)
lars: nobody is trying to shut down the partial reliability discussion - we're talking about this document
harald: we have minimal chance of influence and it seems like we are pushing it away
lars: disagrees. more documents and versions are coming
harald: there's a lot of junk in rfc series such as ipv5 we should worry about the discussion more than polluting the rfc series
spencer as AD: do people have incentive for partial reliability in some other way?
ted: charter presumes PR is an extension. is the document defining applicability of core quic or that of extensions + core? considerations around extensions could be dealt with in a new doc by limiting scope of this doc to core quic and create a new one for extensions
mirija: we can be more explicit about versions.
mnot: thumbs up
mt: take the text if available
gory: ??
jana: martin duke knows
christian: you are worried about making general discussion about specific applications mappings. interop happens at application layer
mk: general classes of application can benefit from advice
ekr: this one is application specific (0rtt)
subodh: +1 to ekr.
mk: can we tell people something useful independent of application
subodh: now thinks general advice would be useful
martin: not enough background - need more look from WG on document (+1 from mnot)
martin duke: new initial is supposed to have same dcid. so in general case this will be routed to same server and we wont have this problem
martin thomson: new version can be flipped during the statless rtt - so it can still happen
kazuho: dcid might change because it is not an invariant
mt: weird to depend on 0rtt settings.
mike: server always goes first
mt: weird. prefer not to have that one. ok having defaults for alleviating hol blocking as long as defaults are simple e.g. no header table use. however hedaer block size is not conducive to that. so in big picture hol blocking is tolerable
mike: not using qpack dynamic table at all is rather a drawback to request size jana: what mt said. also what is the use case for negotiation?
kazuho: use case is that endpoint can wait for peer's signal to decide whether or not create qpack decoder stream. full negotiation just moves blocking part around - prefers negotiation
subodh: worried about offer/select semantics .. and also current state of waiting for settings frame. prefers defaults mode. h2 has a defaults mode as client can speak wout server
alan and dmitri: qpack default size to 0 in impls
eric kinnear: not sure this is a meaningful hol improvement mt: i hear that defaults are ok - but not sure how to impl it. how do i do a header block size default eg? 0 is only safe default but not useful
eric kinnear: yuck wrt different rules from different settings (from off mic).
subodh: 0 means don't compress, not dont send
mt: no. it means no headers
kazuho: h2 .. in tls13 server speaks first, tls12 client speaks first. but in quic we have consistency
jana: outside of qpack, is there another feature that needs offer/select
mike: not at this time. perhaps mutually exclusive extension (different flavors of priority e.g.)
mt: we can deal with that some other way!
mnot: too early to hum. lets see more fleshed out proposals on list
ian: in favor. framing in framing makes it hard to make large content serving work. 0 is currently invalid - so its not overloading a current valid
ekr: mildly in favor
mike: existing alignment is to allow push promise
jana: more in favor. imagine a world without push and then you don't need this.
dmitri: to ian still need to support peers that frame data
kazuho: server timings as trailer is a good use case
mt: accept it and move on
mike: I will close the issue based on feedback
ekr: this is really a fork
mnot: h2 did not deprecate h1
mnot: h2 did not obsolete h1 either
mike b: you should use h2 unless you cant
ted: is there confusion between tokens and names?
patrick: h3 is meant to be a successor to h2 because its better. also h* all have same semantics which is important signal
kazuho: logging will not like anything other than http/* and h2 already said no minor version numbers
spencer: update charter before ad transition
mnot: naming of http needs to stay in http community
mt: this is a fork? mnot: semantics vs wire is what is important
HUMS ON SUPPORTING RENAMING to H3
support hum strongly in favor with non zero do not support. perhaps 70:30
support hum for letting httpbis wg decide: ~100% support
martin d: pr 1819 was meant to allow receivers to drop initial packets. not sure how to bring back the dead PR
marten s: We still need the ACK in 1819. This proposal will require some changes to loss recovery.
lars: out of time!
kazuho: we have this discussion on and off since may - opposed to changing this now because it is an optimization
marten s: its an attack surface issue
9:00-11:00 Wednesday Morning session I, Thai Chitlada 1 - in other time zones
Recap of spin bit: it uses one bit in the short packet header. Client sends bit, server reflects, and the client then flips the bit once it sees the edge of the bit reflected.
Similar to work done in IPPM as alt-mark, except that was two synchronized boxes, while this is end-to-end.
Why? - Interdomain troubleshooting - Quality monitoring - Bufferbloat detection - Internet measurement
Microsoft, picoquic say they will implement
Concerns are: - Geolocation, which was analyzed by design team - Selective spinning, if all clients spin, then ones who don't look odd - Semantics could change between versions
Concerns about robustness, and usefulness. In good conditions, it works very well! Paper shows good results. Susceptible to high reordering.
As an observer, how do you filter out non-participating endpoints?
Paper proposes "valid edge counter" to use two additional bits (but this is out of scope for QUIC now)
Non-explicit edge validation (heuristics and reverse path validation)
Hackathon implemented heuristic at IETF 102.
Reverse path validation handles cases well with 10% reordering and depth of 5ms
Overestimation is not necessarily a problem actually causes earlier action, which may be good. We can filter out underestimation.
Considering doing some hums first prior to discussion to check for consensus.
Potential of IPR disclosure, but none has been made, so discussion is assuming not.
HUM TOPICS - Confirm: decision will be limited to the single-bit variant - Confirm: the spin bit is fit for purpose - Confirm: the privacy/security aspects of spin are well-understood and acceptable - Confirm: intent to implement and deploy - Consensus: include the spin bit in the specification - Consensus: requirement level / negotiation mechanism for the spin bit (if previous consensus achieved)
Christian: does this include the recent PR to make the use of spin a percentage?
Bob: The last point (requirement level) is not well phrased as a question
Ted: For understanding of privacy/security, we must know that it must be possible to not spin
DKG: While there was a reference to ossification earlier, that's not on the hum list. I'm not convinced we know what the ossification risks are.
Subodh: To add to the ossification concern, what's the differential treatment concern?
Richard Barnes: Seems odd to have "acceptable" in the hum confirmation.
(ACCEPTABLE IS REMOVED)
Spencer: As individual; should it worry me if we're asking about sufficient analysis, since not having found concerns yet doesn't mean there aren't any.
Mark: It must be possible not to spin.
ekr: If we miss consensus on any item, do we stop and talk, and if we don't, we're done?
Lars: Yes, if it's inconclusive, we figure it out
Christian: The arguments for several spin bits (VEC and Orange) can do things like detect loss, but the decision indicates that these are out of scope now.
Lars: Yes.
Yes: Strong hum
No: Nothing
Martin: this next question includes whether enough people do it
Bob: It's fit for the purpose for those who want it
Igor: To clarify, it's not everything all operators need, just RTT
Yes: Strong hum (jabber agrees)
No: Nothing
Christian: Two parts about not spinning--I can tweak a bit in my implementation to not spin. But it should also be possible to disable without ill effect of singling someone out.
Lars: Clients, or also servers?
Christian: Definitely includes servers. Both.
Marten Seemann: For p2p applications there's no real distinction between client and server. It must be possible for both sides to opt-out unilaterally.
Sanjay: There was discussion about how to specify that you must spin..
Lars: This eliminates the possibility to "must spin".
Jana: As far as opting out without consequence, there's the question of how to negotiate this.
Mark: Let's talk about that later
Marten Seemann: It seems like you could still have preferential treatment
Martin Thomson: The specific design for opt out is the last item. That's not this question.
Yes: Strong hum
No: Nothing
Ted: Clarifying that everyone should know that this is not in invariants
ekr: These are all three separate items (privacy/security/ossification). I don't think we understand ossification.
Mirja: There has been more privacy/security/ossification analysis than for any other bit in QUIC. Is this understanding what has been discussed, or if there are unknowns.
Lars: I want to confirm that people have the information they need.
Kazuho: I want to point out that for ossification, we have done plenty of analysis for zeroing or randomizing. We haven't discussed using another signal.
Cullen: I don't think we understand these in any protocols! Would the chairs change the question to "do you have enough info today to decide the other questions".
Marten Seemann: There's been an analysis of geolocation, but not for VPN or NATs. You can get the RTT from the VPN endpoint and the server.
Lars: That's just for TCP proxies.
ekr: We previously hummed that you must be able to opt out. I'm not convinced we know how to design a mechanism.
Mark: is that about having enough information?
Ted: Responding to the concern that Marten raised about VPN: it is the case that if you are very far away, you can detect that there is a VPN gateway present. You can't tell where it is, though. It is possible to determine a tunnel is present, but nothing more. If this is a case of concern, make the default to opt out over a tunnel. I am convinced we can mitigate this successfully.
Marcus: On the topic of preferential treatment, the incentive of the network is to use the bit to improve your experiment. If you don't want this at all, a network can just block all QUIC, but they don't have any reason to do that.
Jana: Rephrasing was useful, because we can't always get to the end of all issues. There might be more issues, but we can still make a decision on this for now.
Bob: To Jana's point, these are all dogfights, and various entities will get ahead, and go back and forth. It's enough to say we have enough at this time.
Toma: Even when the RTT is shown to a third party, we can figure out how far, but not where. I haven't seen the analysis of what would happen if a possible attacker could do BGP hijacking and used RTT to limit the possible sources, and enumerates the sources.
Kazuho: By confirming the third issue, we confirmed that the spin bit is optional. That means that this question is "can we propose it as an optional element".
Christian: About BGP hijacking: the spin bit is a tradeoff between privacy risk and network management. Network management can detect BGP hijacking. If we refuse to expose things, it's not necessarily true that everything will be better. This isn't black and white.
Yes: Strong hum
No: Weak hum
Mark: Will more time help any of the negative hums?
Martin Duke: I'm afraid we lost the plot. We remove the negotiation part?
Mark: We're not there yet. That's not the decision we're making now. We're making sure we know what has happened so far.
ekr: As someone who hummed no, I don't presently understand if the proposed design meets the ossification criteria. That's the only reason I hummed against.
Al Morton: We haven't put a green check or red X on this (4). We've emptied the line for the negative. We need to make the call.
Nick Sullivan: To ekr, is ossification equal to discrimination?
DKG: I think discrimination is the ossification concern. I agree that the chairs took the right feel of the room though.
Jana: Can we move on to the last question without closing this?
Gorry: I would like to just move on and decide
Tommy: I think the traffic discrimination can be solved; there may be trailing ossification aspects, but they are more about how we can reuse the bit later.
Lars: We want to know if people will have sufficient traffic.
Tommy: Apple plans to do a majority of spinning on clients
Gabriel: Microsoft does still intend to use it (client and server)
Florin: Broadcom will be exploring using (middleboxes)
Ian Swett: Chrome will not do this, and Google servers are a "may"
Martin Duke: F5 is a middlebox and server and would support in both
Dmitri Tikhonov: LiteSpeed Technologies will implement in client and server
Dan Druta: Will use and deploy as a middlebox
Subodh: Facebook as client and server will most likely not, but reserve the right to enable it
ekr: Firefox does not intend to set the spin bit
Jana: Fastly doesn't intend to do it now, but no promises
Marten Seemann: quic-go won't implement it
No hum, but there are at least some clients and servers that would do so. It is a non-trivial amount of traffic.
Design: - SHOULD/MAY spin/echo - If spin, MUST opt out (some traffic)
Martin Thomson: This is essentially what Brian articulated. I'd like to defer the negotiated versus discretionary discussion
Mark: I wanted that too; some people seemed to gate their decision
Martin: I'd like to litigate that after the fact
Christian: Yes, we have a spec in the spin bit draft. The mechanism to not spin is to provide an anonymity set, the observer cannot detect that the client is trying to protect a particular path. We don't know how to build a foolproof anonymity set.
Christian: The threat of differentiated traffic is a concern about operators harming their own networks. The other concern is about spies watching you and identifying sensitive traffic.
Bob: To state the obvious, you're already exposing your five-tuple. But an operator would never go to that level of discrimination.
Sanjay: Penalizing for not being able measure RTT would be shooting yourself in the foot.
ekr: Is this a hum for the general design space, right?
Mark: yes, with room to improve.
Mirja: You can always block QUIC traffic as a whole. So if we're so concerned if
Yes: Strong hum (4-5 hums for inclusion, no against)
No: Medium-Strong hum (less)
Mark: Seems like 65% in favor. I don't think we can walk away from the discussion.
Lars: Seems like rough consensus to include the spin bit.
Lars: We have a proposal from Brian. That's the starting point. Kazuho has some different design stuff, so look at that discussion.
Martin: I want to conclude the negotiation idea. I think it's a bad idea to negotiate.
Mark: Ten minutes for this.
Kazuho: I think that version negotiation gives a better signal to the observers. They can use the the VN to know that it's spinning. It also provides a way to evolve from the endpoint and middleboxes.
That said, it's only one bit. I'm not strongly opposed.
Ted: Thank you! I strongly believe that making this discretionary is far better for anonymity. The discretionary use is more likely if there is a version explicitly.
Martin: I'm with Ted. You need to lose the signal upon migration to avoid linkability. Gives much more options.
ekr: I concur with Martin and Ted. Negotiation is a bad idea. Extra complexity.
Marcus: As a consumer, I wouldn't trust the version. I can use a signal to ignore spin, but that's it.
David: Agreed, I don't like negotiating.
Mike Bishop: +1
Yes: Strong hum (several hums on jabber too)
No: Nothing
Mirja: Are we ready to merge?
Lars: Yeah, go for it. Ask Martin and Jana.
Christian: I'll probably give another PR about when to opt out.
We have an interim in January in Tokyo. Go to quicwg.org.
Registration ends on December 18. Please register early. Akamai location.
Charter/Milestones has us shipping QUIC RFCs in November. That seems unlikely ;)
The goal is to freeze -17 to let implementers interop and build their full solutions and find inaccuracies.
We push back the milestones to July 2019, Montreal.
We want deployment experience in this time before then.
We can have other discussions about what to do next for QUIC. Interest in these areas:
Multipath
Partial reliability
These efforts should merge their work, rather than having to hash it out in the WG.
Ian: To clarify on the last point, the hope is to deploy -17 at global scale. That's the intent, right?
Lars: Yes, that's the intent. We can -18 if we need to make it better.
Martin Duke: To clarify, if we "freeze" -17, what's the status of open issues? Are the rest punted to v2?
Mark: We have the v2 and Parked labels. We can look at Parked, and consider them.
Martin Thomson: I've gone through all parked and v2 issues, and my view is that we can have very short discussions on all of those. My expectation is that parked with either be closed or merged as minor, or punted.
David Schinazi: I agree with the goal to get experience on -17, but would it still be reasonable to test the extension mechanism before we ship? Can we get some experience with one extension first before we go to RFC?
Martin Duke: If we talk about next steps, I'd like to consider adopting load balancing.
Jana: I expect some churn in the recovery draft, just to let people now. We should continue to engage there.
ekr: Following up on Ian, one thing that didn't go as well for TLS 1.3, we had a bunch of small draft versions, and it got annoying to interop. It may be better to have larger checkpoints.
Mike Bishop: With subsequent small drafts, if there's no wire image change, just editorial, we could have a "version number to use" and stick on an old one for editorial only changes. We can skip versions.
Martin Thomson: Let's not discuss now what the interop goals are, take that to the list.
There was a QUIC human rights review done outside the WG. It was on the agenda to get feedback, and that is being done in the human rights group.