IETF-83 hybi agenda Session 2012-03-28 1300-1500: 252B - Administrative / Agenda bash (Chairs, 10') - New Charter overview (Chairs, 10') Good progress: WebSocket protocol published as RFC6455. Now: the new charter is focused on topics we left out of the base spec: compression, multiplexing, timeouts 2 calls for adoption succeeded and finalized: compression and muxing drafts. ----- PerFrame Deflate draft (Takeshi, 30') ----- draft-tyoshino-hybi-websocket-perframe-deflate-06.txt Roberto Peon: be very clear about max window size to limit intermediary buffers. Already designed that way. How to negotiate new compression algorithms? - choose between header or extension parameter for algo parameter Ian Fette: avoid new header. => to be discussed on the list Willy Tarreau: like option 1 (compress-alpha) rather than option 2 Using a reserved bit for this? Yes, this seems consensus. Ian: it would be preferrable to automate this in the browser and compress if we see a gain transparently to the app. No API changes. Martin Thomson: why per-frame? Need more justification. Why deflate versus others? Patrick had some justification. To add a paragraph to the spec. On APIs: Thomas says this can be done either by taking the API out of candidate recommendation (NO) or by simply revving it to a 1.1 after we're done. Gabriel to handle the API issues with W3C. ----- Multiplex draft (Takeshi, 45') ----- draft-tamplin-hybi-google-mux-03.txt - Gabriel: clarify that FC frames must not be fragmented : how to prevent them from being fragmented by intermediaries. Issues there? Yoshino san doesn't think so. "lightweight" channels? Send data along with AddChannel or absolutely wait for response RTT? Like SPDY, perhaps can be done. Gabriel: should not be a problem to send data after AddChannel without waiting for response Why 4 different encodings for a channel? This seems too complex, perhaps 2 at most? Action - open a ticket in the issue tracker Gary ? From qualcomm: how is masking done? Ans: Masking is separate from muxing Gary: any changes to JS? Ans: no changes Ian: JS just says new "websocket" and that might end up creating just a new channel, transparently to JS ???: why not support priorities (eg: for control channel) Flow control still needs to be discussed: Ian on Roberto's request for flow control. Please clarify. Roberto Peon: if flow control is up to implemento it won't work Roberto: Intermediaries should not have to have infinite buffer, so some algoritm for flow control should be applied and agreed upon. From Peter: check with Transport Area folks about this. Ian: how do we know if multiple requests can be coalesced into one same physical channel? Ans: Hostname and port. Ian: on w3c this work on mux and compression has not started. Thomas Roessler: what requirements are there on API? If any, it is time critical (within 4 weeks) to do this. Patrick: agree with most that this is transparent.But, perhaps apps want to express for a given websocket do NOT coalesce, but make it a separate connection. Thomas: that seems like future. Will Chan: TCP resets can wreak havoc, what to do? Ian: we have Ping/Pong Ted Hardie: are these multiplexed? Ans: perhaps space for per-channel keepalive mechanism. ----- Timeout proposal (Martin, 15') ----- draft-thomson-hybi-http-timeout-01.txt Any proxies that are aware of these? Ericsson (per Salvatore) has some in telco networks. Roberto: this could just be a lie, if so, why send extra bytes? Ian: same as long-lived SPDY? Roberto: we have a Ping similar to WS'. Not intended to keep the connection alive, but just a liveness test. Assan Khalil (google). In spdy we use ping only as liveness, enforced by shutting down connection that have ping frames with nothing in between. Martin: load balancers and NATs drop connections without warning Will Chang (chrome): we get lots of issues, we just have TCP keepalives every 45 sec. With a POST (which cannot be repeated) send a Ping either at the same time or right before it. Martin: you might lose your POST and have no idea why. Will: yes, and this is worse with coalesced muxing case. Roberto: spdy ping is a p-p thing and the server should respond immediately. If you have not then you can shut down the connection. Anything you do in mobile devices that turns that radio on more than needed, means the feature will be turned off. Assan: you can send a ping before and after a POST. But don't see a value for keepalive. Martin: seems like there is some confusion. This is not telling anyone to send anything. Patrick: took keepalive approach in firefox to test the other approach. He has a live connection so doesn't have to race a poing against a Pong. ----- Open discussion (e.g. subprotocols) (all, as time allows) ----- Websockets over SPDY? Ian - Google has thought about this. Currently leading towards keeping SPDY as a transport protocol that sends bit and WS goes as-is on top of that. Roberto - my preference is not very strong, but it is that WS should be translated into SPDY.