{"id":9768,"date":"2018-06-11T06:00:59","date_gmt":"2018-06-11T10:00:59","guid":{"rendered":"https:\/\/blog.litespeedtech.com\/?p=9768"},"modified":"2018-06-11T06:00:59","modified_gmt":"2018-06-11T10:00:59","slug":"developers-corner-quic-kista-interim-day-2","status":"publish","type":"post","link":"https:\/\/lswp.store\/index.php\/2018\/06\/11\/developers-corner-quic-kista-interim-day-2\/","title":{"rendered":"Developer’s Corner: QUIC Kista Interim Day 2"},"content":{"rendered":"

\"Developer's<\/a><\/p>\n

Explicit Congestion Notification<\/h2>\n

The second day of the Kista Interim Meeting began with the Explicit Congestion Control (ECN) presentation<\/a> by Magnus Westerlund. The proposal to add ECN to QUIC has been around since at least January of 2017. A year and a half is a long time in the context of an IETF Working Group! In January of this year, Ingemar Johansson presented the proposal to the WG at the Melbourne Interim<\/a> but it was still deemed to be lacking. This time around, the result was different. Over the last several months, Magnus and Ingemar (colleagues at Ericsson<\/a>, our gracious host) prepared a comprehensive presentation along with a GitHub pull request<\/a> that incorporates ECN into the QUIC protocol.<\/p>\n

The Working Group adopted the proposal. Of course, some parts will have to be changed. This is inevitable in a large proposal such as this one. For example, there was a marked pushback against adding a second frame type to carry acknowledgements (named ACK_ECN<\/i> in the proposal). It looks like the existing ACK<\/i> frame will be augmented to support additional ECN information. At one point in the discussion, Brian Trammell suggested that we add SMACK<\/i> (small ACK) and SHACK<\/i> (short ACK) frames to the protocol. But he was only joking. I think.<\/p>\n

QUIC @Facebook<\/h2>\n

Subodh Iyengar shared experiences<\/a> implementing and deploying IETF QUIC at Facebook. It is rather impressive that Facebook is running IETF QUIC now<\/b>, while the protocol is still shifting under our feet. Since HTTP\/QUIC is not yet ready, the folks at Facebook use QUIC as the transport for HTTP\/1.1. The setup carries 100 billion HTTP requests per day.<\/p>\n

\"QUIC<\/a>
Facebook Load Balancer Architecture, taken from Subodh\u2019s slides<\/figcaption><\/figure>\n

I already knew about Facebook\u2019s pioneering ways. During the Seattle Interim<\/a> in 2017, Alan Frindell told us that Facebook has been running experiments (in production, of course) with the different HPACK successors. Having worked a bit with the Facebook code, I know that they are not afraid to use the hot-off-the-presses C++14 features.<\/p>\n

This sort of \u201clessons learned\u201d disclosure is a very valuable contribution both to the working group and to the implementers of the nascent protocol. The Working Group can see what shortcomings there are in the protocol, so that we can address them early. The implementers avoid committing the same errors, saving valuable time.<\/p>\n

Well done, Facebook.<\/p>\n

QUIC Load Balancers<\/h2>\n

Martin Duke presented<\/a> his QUIC Load Balancers draft<\/a>. The draft proposes a way for QUIC load balancers to update each other\u2019s state to allow them operating correctly even if there are connection migrations. The load balancers would talk to each other using (naturally) QUIC-LB protocol.<\/p>\n

Implicit Stream Open is In<\/h2>\n

In my first Kista Interim Summary post<\/a>, I stated that the requirement to open streams in order is without merit. While I still oppose the implicit open, I have come to see the other side\u2019s perspective. Yes, the implicit open carries more information with each STREAM<\/i> frame, making it simpler to keep track of some things. I still oppose it, for the drawbacks are more significant.<\/p>\n

This time around, this issue came to a head and we hummed. Outhummed I was. The consensus is to have implicit open. Well, what\u2019s done is done and life goes on. This issue is comparatively small, and it is not like we were assigning stream IDs out of order anyway.<\/p>\n

PNE Negotiation<\/h2>\n

Packet number encryption (PNE) negotiation, championed by Praveen Balasubramanian, was rejected by the Working Group. Praveen advocated the data center use case, where PNE is unnecessary and only adds processing overhead. The Working Group\u2019s consensus was that PNE is an intrinsic part of QUIC v1. Not having it means a different protocol, which cannot be called QUIC v1.<\/p>\n

The Bad<\/h2>\n

The audio. The audio was bad. The audio was bad as usual<\/b>, which is also bad. I do not expect a United Nations level of audio setup, but a little extra effort would pay off a lot.<\/p>\n

While the chairs\u2019 microphones were good, the two omnidirectional microphones used to pick up comments from the two or so dozen of the other participants failed to serve adequately. Many people are not used to the idea of projecting their voice. Indeed: when you are speaking to people who are fifteen feet away from you, raising your voice is unnecessary. The end result is that I at times had trouble following the discussion.<\/p>\n

Next Interim: NYC!<\/h2>\n

The current plan is to hold the next Interim Meeting in New York City. How convenient: the QUIC brain trust just a train ride away from my house!<\/p>\n

\u201cLive from New York, it is the IETF QUIC!\u201d<\/i><\/p>\n","protected":false},"excerpt":{"rendered":"

Explicit Congestion Notification The second day of the Kista Interim Meeting began with the Explicit Congestion Control (ECN) presentation by Magnus Westerlund. The proposal to add ECN to QUIC has been around since at least January of 2017. A year and a half is a long time in the context of an IETF Working Group! […]<\/p>\n","protected":false},"author":1,"featured_media":9776,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[18],"tags":[88,143,238,240],"class_list":["post-9768","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-conferences","tag-developers-corner","tag-ietf","tag-quic","tag-quic-working-group"],"jetpack_featured_media_url":"https:\/\/lswp.store\/wp-content\/uploads\/2018\/06\/dev10.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/posts\/9768","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/comments?post=9768"}],"version-history":[{"count":0,"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/posts\/9768\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/media\/9776"}],"wp:attachment":[{"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/media?parent=9768"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/categories?post=9768"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lswp.store\/index.php\/wp-json\/wp\/v2\/tags?post=9768"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}