source: wg_materials/ietf87/minutes.txt @ 2719

Last change on this file since 2719 was 2360, checked in by mnot@…, 7 years ago

clean up Wednesday minutes

File size: 21.5 KB
Line 
1# Minutes
2
3HTTPbis Working Group - IETF 87, Berlin
4
5## Wednesday Session
6
7### HTTP/1.1 Issues
8
9We discussed a number of issues in Trac, including #470, #475, #458, #345, #455
10and #486. No decisions were made, but the editors were able to discuss their
11status and allocate owners; expect proposals to be incorporated in the next set
12of drafts and/or discussed on list.
13
14### Known Startup State for HTTPS
15
16Gabriel presented to see if we agreed that we need to request TLS provide a
17mechanism for conveying the startup state for HTTPS; however, we did not yet
18reach consensus on this, as it was felt it needs more discussion.
19
20### HTTP/2 Issues
21
22We did a run-through of the open issues to triage them for the upcoming Hamburg
23discussions. In this process, we were able to close a number as already
24incorporated in the -04 draft.
25
26We agreed that for isssue #174, it should change to MUST.
27
28
29## Friday Session
30
31Note well reviewed. Mark review the agenda: HTTP and Encryption, HTTP/2 with a
32Transport Eye (Allison Mankin), 20 Min Flow Control, 20 Minutes Priorities, 20
33min Initial Congestion Window 20 Min General Discussion/Other issues. He notes
34that the primary reason for the meeting was to give a joint meeting with the
35Transport Area, but because of recent events he and the Security ADs felt that
36it was timely to have a short discussion (time bound to 15 minutes) on
37encryption. The transport discussion will follow.
38
39### HTTP and Encryption
40
41Next Presentation, also by Mark, begins, on HTTP & Encryption. HTTP/1.1 has no
42Mandatory to Implement to Security; that was an artifact on how long its been
43around (Larry Masinter disagrees with this characterization; the rational for
44allowing connections to remain un-encrypted was the same then as now. This
45discussion was delayed). SPDY introduced Madatory to Use Security; this was
46discussed for HTTP2.0; the working group declined, because of use cases like
47back end services. The status quo is: Server Chooses whether encryption is used
48or not--if the server does not offer encryption with an https URL, the client
49cannot use it. It is an assymetric relationship.
50
51There is new information; there are widespread deployments of sniffers. More
52details have since been released. As Chair, Mark felt that this was enough to
53re-open the discussion. He suggests a few proposed actions--these are the start
54of the discussion, not an ending. Martin notes that the scheduling conflict of
55TLS being against this working group means that many who care are not present.
56Mark splits the discussion into HTTP/1.1 and then 2.0. Mark notes that there
57are limits on what we can do for 1.1. He proposes that we document the
58asymmetry and the consequences; while it does not do more than describe the
59issue, since we are re-describing the properties of the protocol, it would be
60good to do. See slides for the proposed additions, but “servers out to
61implement and prefer HTTPS”. That’s not necessarily adequate, but more might
62come from TLS as they document the security properties of their protocol. He’s
63not looking for lots of discussion, but a sense of the room of publication of
64something like this. Two hums: do we want to pursue documenting this in the
65security considerations in the 1.1 drafts (probably in the first document in
66the series)? Alternately is that not a good idea?
67
68Gabriel notes that the choice not to send packets is always packets. Larry
69notes that he believes this is political theatre--there is no technical
70judgement that you can apply here. We should focus on the technical work here.
71Mark agrees that there may be a bit of political action here, but notes that
72the security considerations already have many corner cases reflected, and doing
73those and not this seems odd. Barry asks if there are implementations that do
74not implement HTTPS? Yes.
75
76First Hum: is this an interesting discussion for documenting in our HTTP/1.1
77document? Strong Hum. The reverse: a much weaker but still present hum. Mark
78says that we will continue on the list, but will cut it off if it becomes a rat
79hole.
80
81Proposed HTTP/2.0 discussion of the same topic begins. New issue, since this is
82a new protocol. Mark wants to introduce the idea of equal power; a client can
83negotiate/require use of encryption for HTTP URIs. He would like this
84discussion to become more explicit. The second piece is proxy
85discover/interactions. The interposing proxies need an answer for this; the
86user needs to understand what is happening and have an opportunity to say that
87no, this is not what is happening. We need to think more carefully about
88protocol interactions. This is *NOT* about enabling man-in-the-middle
89interception of encrypted traffic. The documentation of HTTPS is for end-to-end
90security and that will not change. Liaison with TLS and W3C may be required.
91For the HTTP 2.0, he would like to take those hums.
92
93Larry Masinter notes that the topic was mandatory to implement security, but
94some of what he said was not the same. Mark says “mandatory to offer” is closer
95to what he said. Larry said proxy behavior taxonomy may be necessary. Mark
96notes that if we disenfranchise proxy use cases, we will have deployment
97problems. Gabriel Montenegro believes that encouraging the use of encrypted
98capabilities is wonderful, but he wants to understand if this disallows parties
99speaking without encryption? Mark clarifies that if both parties truly want to
100use a clear channel, it should be possible. Greg Maxwell notes that it may be
101useful to distinguish between security and encryption--e.g. authentication may
102require other costs over and above those of encryption. Bob Briscoe of BT. He
103hasn’t been involved since 1995, but had come for the transport bit. He wonders
104if from the proxy point of view the least it can do is stop the bits flowing
105(client present this to a user--the proxy says “use me or you are out of luck”).
106
107Who believes that these issues are worthy of further discussion: Hum in
108support:strong hum. Hum against: silence. Good, and we are now at the end of
109the alloted time for this.
110
111### Transport Joint Meeting
112
113Next topic, Allison Mankin’s presentation, “HTTP2.0 with a TSV Eye”.
114
115Allison introduces herself as the TSV technical advisor to the WG. Motiviation;
116the transport area decided it would like someone with TCP to follow the work,
117but this is still an individual’s perspective. She hopes to foster a
118constructive, ongoing relationship. She introduces her “phrase book” for
119traveling between areas. Puts up examples “hop-by-hop, flow control, streams”,
120even transport (e.g. optical transport vs. transport protocol). That means that
121the ability to skim is limited--review needs time.
122
123She then puts up the 5 myths format. Myth 1--that http 2.0 might not address
124and mitigate the use of many concurrent TCP connections. Myth 2--that HTTP 2.0
125may try to appropriate/duplicate windowing and data management roles of TCP.
126Myth 3- that HTTP 2.0 may try to move congestion control and avoidance into the
127application, possibly replacing TCP with a streamlined transport without native
128congestion control and congestion avoidance. Myth 4-- that prioritization in
129HTTP 2.0 is related to (and/or clashes with) priotization implemented in
130various transport and lower layer protocols. [Mic lines were asked to stand
131down, so that the story can complete; note that others may have other views]
132
133Goes into Myth Busting. For Myth 1, notes that HTTP/2.0 work so far clearly
134does reduce the need for concurrent TCP connections and the working group is
135focused on this. For Myth 2, the frame and streams mentioned do not match the
136transport concepts--they serve application processing needs; this is a
137travelers’ phrase book problem. Myth 3, HTTP2.0 has flow control functions;
138this is not the same as CA/CC. This is *application service flow*, not the flow
139of the transport. This allows the system to serve well-recognized HTTP
140intermediaries. Some of this text is confusing to those coming with a transport
141eye, but this is still a myth we can bust. For Myth 4, these are not associated
142with QoS, and are not described in a way that matches up with transport types
143*but* there is some language connecting priority frames connect to the
144bandwidth delay product, so it may be something to examine for transport folks.
145
146Myth 5 (the bonus myth) is that HTTP 2.0 leads to the replacement of TCP by a
147new transport. Are there discussions of replacing TCP as the substrate of HTTP?
148Yes, there are discussions of this, but the HTTP 2.0 work item is unequivocally
149tcp-mapped. The initial congestion window experiments were removed from the
150spec. TCP-Minion and QUIC are both coming along. TSV has long acknowledged that
151applications can ask for things which are not the basic byte stream. SCTP,
152PR-SCTP DCCP are actually representations of the transport aim to meet the
153needs of other customers. So work of this type is not a problem.
154
155Allison also compliments the WG on its intensive work style. Frequent interim
156meetings, github working methods, and the development of a state diagram for
157the stream lifecycle. There are still points for TSV review. GoAWAY and
158RST_STREAM; this still in need f review. TSV style review of the risks of
159off-path attack in general--the area is sadder but wiser about these. TSV style
160review of data integrity issues, e.g. binary and compressed headers. Weak TCP
161checksum failure probably furthers case for “TLS everywhere” in the HTTP2.0
162world.
163
164Going forward, TSV needs close listening, close reading of the review. Also
165looking at research on SPDY versions may help TSV folks; pace of innovations
166should be resonant to TSV folks. Finally, A gratuitous photo fo TIergarten
167tapir (see slide for the photo)
168
169Mark thanks Allison for her presenation and the mic lines filled--most of the
170technical topics are queued up for later sections.
171
172Eliot thanks Allison as well. He notes he has seen at least one person do even
173more just-in-time presentation (3 seconds in advance). For the weak TCP
174checksum issue, TLS is not required, so we cannot rely on it. Allison says it
175may be a carrot for using TLS, not a full requirement. It should come up. Mark
176steals the front mic, and notes that some folks have considered asking for a
177checksum for the headers themselves.
178
179Bob Briscoe wants to go through 3 of the myths from a different view. The first
180one--slowing the growth of more flows; there is a problem the other way around.
181It is not about HTTP is doing, it is about what TSV is doing to incentives
182using more flows (e.g. in RMCAT measuring whether two flows are getting
183fairness, rather than looking at session level. AQM presents a similar issue
184(e.g. in fq_codel)). In message flow control myth, notes that TSV *does* have
185expertise there as well and may be able to help. Allison notes that the
186document notes that it can evolve and more work is needed. On the question of
187stream handling, Bob reiterates that there is a lot of work in TSV on this
188topic, and he wonders if we will end up duplicating. Early recognition of this
189is useful. Bob also notes that there is a lot of work on latency going on,
190TCPMaint is where most of that is going on, but AQM as well. TCP fast open,
191work on reducing the length of slow start; there has been work on TLS false
192start as well.
193
194Jim Gettys cannot overemphasize of the impact and collateral damage that HTTP
195has already imposed on the internet, limiting RTCWEB and other work. Points to
196his blog, which describes the way in which HTTP1.1 was deployed gamed the
197system in its own favor. Bufferbloat and HoL are well known, but the damage to
198everything but web browsing is very heavy. We have to drain a swamp. We don’t
199want to be here again in 10 or 15 years to stop another gaming of the
200transport. He really wants people to understand minion and its potential
201deployment path--he believes that the work can serve the web really well, and
202it has a straightforward deployment strategy. It will give you a lot of what
203the web needs. Cross-fertilization between that work and this needs to go
204forward.
205
206Michael Tuexen continues the theme and wants the cooperation between this
207working group and the transport. In particular, what features and services
208would be valuable is really needed (byte stream? something else?). Other things
209are on the table: quic, sctp/udp. Mapping from candidates to services needed,
210then deployment considerations.
211
212David Black here as a STORM co-chair. There is already precedent with a weak
213checksum (iscsi defines its own checksums). He suggests that there is an
214opportunity to have a header checksum and a data checksum; this works well
215through proxies. These checksums are defenses against flaky behavior, not
216malice. If you want the latter, you need something else, e.g. TLS.
217
218Larry Masinter--of what you discuss, measurement may be the critical one; we
219need to see that http2.0 will be better in the real world. Transport has more
220experience measuring in this area and cross-fertilization would be good.
221Gabriel Montegro sees two subdivisions of this dialog--what is TSV doing
222independently of us (e.g. general services work). The other is describing our
223layering more explicitly so that it becomes easier to re-layer on other things.
224A different dialog would be when HTTPbis is doing “transport-like things”, we
225can get help from TSV on approaches. Flow control is one example, as the
226principles and algorithms may be common or pluggable. The other point is what
227you mentioned about window shrinking--both TCP and SCTP strongly discourage
228window shrinking (should not, not must not). In the web, there is confusion
229when it does happen; that may also be something we can take in and learn from.
230
231Michael Sharf, co-chair of TCPM, emphasizes that it is a bi-directional
232relationship; we need insight from you for evolving TCP (and TCP is still
233evolving). TCP recently published an experimental RFC for increasing the
234window. We also have the work on fast open, which may fit well here, since it
235is focused on latency. We are interested in input there, especially on the
236semantics for applications. Input is very well. Lastly, we have a working group
237item on congestion window validation. These may be of interest to you, and may
238be a place of
239
240Martin Stimmerling plus ones Michael’s words, but also wants to reinforce that
241you need to work on what’s there--looking at minion and quic is great, but we
242need to run on what’s there. Mark notes that the timing with minion is
243problematic as adopting it now would give best results, but it is not ready.
244Jana thanks folks for this meeting. He wants to say transport that we’ve been
245shy about talking about APIs, and that may have been a problem. We create
246exhaustive but not very useful lists of transport features. We need application
247developers to see APIs in clearer terms and expose them in clear terms--a
248service model. Gorry Fairhurst notes that API discussions are *not* banned;
249David Black plus one’s. As a Transport AD, Spencer pointed out that Jana did a
250touchdown sign with both hands when he got that statement. Michael came up to
251say that TCPM was rechartered and that API work is in scope. Much rejoicing in
252the room.
253
254Jim Gettys points out that this interaction showed the value of flow queueing.
255He then reiterated that a lot of this reinforces the language issues; we need
256common vocabulary.
257
258Roberto Peon notes that *deployed* features are the first order bit looked at
259by applications; is it there and will it be available are more important than
260any other features. SCTP, if it had gotten past the chicken and egg, would be
261used today. Roberto also noted that we have had implicit rather explicit APIs.
262
263Mirja Kuehlewind notes that she has tried to follow the HTTPbis work, but it
264has been hard because there is so much going. Mark Nottingham pointed to the
265wiki and github pages.
266
267Michael Tuexen went back to the *services* view; exact socket options may be
268too detailed a question. The key question is whether the service is available.
269That may be available in ways that are not direct APIs--e.g. SCTP over UDP. A
270list of service requirements may be important for deciding if they can be made
271available, rather than what the socket options are. Mark wonders if there is a
272list of available services; Michael pointed to a previous set of slides (and
273audio stream). Mark looks for stuckees to own chasing this? Michael says he
274will be happy to help. Janardhan Iyengar suggest that we have taken a jab at
275this in minion, but it would be great to generalize that. Will Chan asks what
276it is that TSV wants HTTPBIS would describe? He feels like the elephant in the
277room might be QUIC. He wonders if folks are looking at this services question
278because folks are wondering why people went to QUIC.
279
280Michael Tuexen says HTTPBis needs to say “here are the features that we need”
281that are important enough that we would consider changing the transport
282protocol. Will Chan notes that we have not done that within HTTP so far--we are
283building on TCP. Mark Nottingham notes that he feels a wish list exercise might
284be a time sink for his working group; he feels it should be transport area,
285hopefully not for selfish reasons. Gorry notes is is Transport and Services, so
286it would be good to restore the S. He also says that it would be good to have
287that list with a focus on what is really needed, not a wish list.
288
289Martin says we have offered QUIC time at the TSVWG, and they have been told
290they will come, but later.
291
292Andrew McGregor notes that there is knowledge in AQM on how to make
293message-based transports work well, and it may be useful to coordinate there.
294He also notes that splitting the agenda and publishing different conflict lists
295would be useful.
296
297Roberto notes that he has a list here, and he can send it out, but he believes
298transport people know all of it and are working on it, but it needs to get
299deployed.
300
301Patrick McManus knows the transport area and has been active there, but he is
302here as an HTTP 2.0 guy. In that guys, he notes that the effort is to work with
303TCPs that are in the wild. Those are the transport equivalent of our middlebox
304discussion--what can we do in those constraints? Mark agrees that this is a
305good point. Patrick also notes that we can still work on these and share data,
306but note that deployment and iteration is critical.
307
308Will Chan then presents some data on initial congestion window data. Data not
309on agenda, but will be uploaded. He shows a slide of data from Chrome’s beta
310channel users (not all uses, but a small set that have opt-ed in to sharing
311anonymized data). Roberto notes that “small” is relative, but statiscally
312significant group. Will explains the SPDY setting that was a persistent setting
313used when there was a successful, graceful close. Chart limited to stable
314connections (100kbs or more of data). The x-axis is CWND in packets; the y-axis
315is the percentile (histogram). Notes that SPDY connections are initialized to
31632, which is the default for SPDY. Lars asks if this available as a CDF? Yes,
317that’s the next graph. Shows the data. Patrick McManus notes that they have
318“extremely” similar data. Allison notes that a fairly significant number have a
319reduced window by the end of the session (initial congestion window of 32,
320except when information is present which otherwise colors the data). A lot of
321the reason it is below 32 is because of that.
322
323Larry asks if there is data from mod_spdy or others? Will Chan says that Google
324does not have that data. Lars Eggert notes that TCPM had a large discussion on
325this and came up with 10? Why is that Google is using 32 for this instead of
326iw10? Basically because it is trying to compare experience with a multi-tcp
327connection experience of 50 or so because of domain sharding; that’s 500 at
328iw10, vs 32. Martin suggests that this discussion should continue in TCPM,
329instead of here. Will Chan takes an action to have it done--he may pass it to
330Jerry or someone else.
331
332Jim Gettys goes back to collateral damage creating head of line blocking in
333sigle queue devices--creates 100s of milliseconds of latency in broadband
334scenarios. If you want RTCWEB to work, you need to get this solved. Will Chan
335notes that we are providing a platform--if the apps on the top of the platform
336try to game the system. Jana notes that host limits on the connection provide
337limits 6 doing 4 wouldn’t be much better and it can be much than 6 connections.
338We can talk about this, but it is a problem worth solving.
339
340Bob Briscoe hides a possible myth or fallacy about the ability to use a large
341congestion window. This is a clocked window at the termination, but not clocked
342at the restart. If you have a server interface capable of pacing, that you
343could get some of this advantage back. Will Chan notes that we have already
344removed this from HTTP 2.0; Bob notes that it would be good if we can get it
345back. Will agrees, but he clarifies that the existing mechanism was flawed, and
346that he recognizes.
347
348Eliot Lear asks if this based on IP address? No. Will clarifies that this is
349essentially a cookie--the client connects based on a stored setting.
350
351Martin Thompson possible exhibits a bias that some web applications may not
352have the same characteristics because of the server distribution--for many
353people this will be within low RTT. Jokes about CDNs ensue. Mirja reiterates
354that this is a TCPM topic, and it is scary that it is being presented here for
355the second time. Mark clarifies that this is the first HTTPbis has seen the
356data. Mirja is concerned that a solution coming from other groups may not have
357the right data.
358
359Will notes that Google runs lot of experiments. Jerry Chu notes that he has
360been working with this data and he has been trying to share it. They are
361working on pacing now as a result. Mark asks for continuing that information
362sharing.
363
364Martin will invite the HTTPBis folks to come to the transport area meeting.
365Mark says thanks and encourages clear agenda items to encourage participation.
366
367Then next meeting is Hamburg, next week.
368
Note: See TracBrowser for help on using the repository browser.