source: wg_materials/ietf87/minutes.txt @ 2359

Last change on this file since 2359 was 2359, checked in by mnot@…, 9 years ago

line wrap minutes

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