Changeset 2359


Ignore:
Timestamp:
Aug 22, 2013, 8:44:17 PM (6 years ago)
Author:
mnot@…
Message:

line wrap minutes

File:
1 edited

Legend:

Unmodified
Added
Removed
  • wg_materials/ietf87/minutes.txt

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