IETF
httpbis
httpbis@jabber.ietf.org
Tuesday, 6 November 2012< ^ >
stpeter has set the subject to: IETF HTTPbis Working Group | http://tools.ietf.org/wg/httpbis/agenda?item=agenda-85-httpbis.html
Room Configuration

GMT+0
[05:21:02] Eliot Lear joins the room
[05:35:02] Eliot Lear leaves the room
[07:45:24] mbelshe joins the room
[07:50:59] mbelshe leaves the room
[07:59:12] mbelshe joins the room
[08:57:29] mbelshe leaves the room
[09:11:00] mbelshe joins the room
[09:11:39] tony.l.hansen leaves the room
[09:11:43] tony.l.hansen joins the room
[10:31:02] mbelshe leaves the room
[11:33:13] hillbrad joins the room
[12:00:15] hillbrad leaves the room
[13:02:14] tfossati joins the room
[13:34:37] frodek joins the room
[13:35:50] Ben Niven-Jenkins joins the room
[13:39:40] frodek leaves the room
[13:42:01] Ben Niven-Jenkins leaves the room
[13:43:37] frodek joins the room
[13:48:41] Dowon Kim joins the room
[13:49:43] Gabriel Montenegro joins the room
[13:52:01] Martin Thomson joins the room
[13:54:14] hillbrad joins the room
[13:55:53] kazubu joins the room
[13:56:42] SM joins the room
[13:58:10] Dowon Kim leaves the room
[13:58:18] julian joins the room
[13:58:32] barryleiba joins the room
[13:59:39] mbelshe joins the room
[14:00:02] yuioku.yj joins the room
[14:00:03] <mbelshe> hello
[14:00:34] Dowon Kim joins the room
[14:00:43] m&m joins the room
[14:01:46] fenton joins the room
[14:03:01] joseph.yee joins the room
[14:03:09] lef.jpn joins the room
[14:03:23] hildjj joins the room
[14:03:24] Ken Murchison joins the room
[14:03:52] cabo joins the room
[14:04:03] fielding joins the room
[14:04:14] bkihara joins the room
[14:04:21] =JeffH joins the room
[14:04:28] msk joins the room
[14:04:44] <hildjj> I will relay your comments and questions from here to the room. Please prefix your text with "mic:" to request this service.
[14:04:46] Atarashi Yoshifumi joins the room
[14:04:57] julian thanks Joe
[14:04:58] <=JeffH> mnot: <agenda bashing>
[14:05:04] <msk> hildjj: crickets
[14:05:24] <hildjj> msk: please use the physical mic if you're in the room. :)
[14:05:44] <=JeffH> issue-385
[14:05:53] <=JeffH> aka ticket #385
[14:05:56] cyrusdaboo joins the room
[14:06:01] <=JeffH> upgrade mechanism
[14:06:39] <julian> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/385
[14:07:43] <Martin Thomson> http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html
[14:08:43] danwing joins the room
[14:09:37] <=JeffH> see thread rooted here: http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html
[14:10:13] <=JeffH> ok, so mnot will send the message suggested in that above message to the tls chairs and show up in the TLS session this afternoon
[14:10:25] <=JeffH> oh http side of things I(see above msg)
[14:10:28] <=JeffH> .....
[14:10:35] danwing leaves the room
[14:10:49] <tony.l.hansen> no one is updating the etherpad
[14:11:37] <=JeffH> dunno if anyone is signed up to do that
[14:11:58] danwing joins the room
[14:12:41] <fielding> http://tools.ietf.org/id/draft-montenegro-httpbis-http2-negotiation-00.txt
[14:13:16] <Martin Thomson> alternate protocols:
10: HTTP/1.1
20: HTTP/2
30: goto 10
[14:13:52] stpeter joins the room
[14:13:53] <=JeffH> Gabriel M. is going to present on upgrade-based negotiation for http/2.0 -- which is one approach to addressing the issues in the "http uris" section of the issues outlined in the <http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html> mail msg
[14:13:58] <tony.l.hansen> or for visuals
[14:14:03] <=JeffH> slide 1: role of upgrade-based negotiation
[14:14:33] <mbelshe> are these slides online?
[14:15:20] <hildjj> http://www.ietf.org/proceedings/85/slides/slides-85-httpbis-2.pdf
[14:15:29] <hildjj> In general: https://datatracker.ietf.org/meeting/85/materials.html#wg-httpbis
[14:16:30] <=JeffH> slide 2: proposal
[14:16:42] <=JeffH> thx hildjj
[14:17:06] PHB joins the room
[14:17:24] hardie@jabber.psg.com joins the room
[14:18:06] Eliot Lear joins the room
[14:19:14] <=JeffH> roy at mike: don't need to prefix the header fields
[14:19:24] <=JeffH> roy: they're just header fields
[14:19:36] <=JeffH> mnot: it's side chan info, for optimizing
[14:19:56] <=JeffH> roy: as soon as sent in http1.1 they're just a header field, register them, don't need prefix
[14:20:10] <=JeffH> back to preso....
[14:20:46] Zhiwei Yan joins the room
[14:20:46] <=JeffH> joe hildbrant (jhil) @mic:
[14:20:57] <=JeffH> wud those http2 things get stripped out?
[14:21:29] <hildjj> "hildebrand", but close enough
[14:21:33] <=JeffH> gabriel m (gm): yes
[14:21:48] <Zhiwei Yan> NO VOICE?
[14:21:50] <=JeffH> hildjj thx
[14:22:00] <mbelshe> mic: have any tests been run to confirm viability in the wild? as presented before, data shows port 80 has trouble with non-http1.1 protocols. or do we just want to ignore that?
[14:22:22] Zhiwei Yan leaves the room
[14:22:24] <=JeffH> can folks hear audio now ?
[14:22:35] <Eliot Lear> sounds good
[14:22:37] <=JeffH> k
[14:22:56] <=JeffH> mnot sez to mike belshe (mb) -- we're getting there
[14:22:57] <tony.l.hansen> i can hear you
[14:23:05] <fielding> it is not an issue
[14:23:10] <hildjj> mbelshe: let me know if/when you want me to repeat.
[14:23:20] xiaohong.deng joins the room
[14:23:33] <mbelshe> i assume you're asking to speak about this later... will hold question?
[14:23:48] <mbelshe> or maybe mnot is saying that we're getting data that it will work
[14:24:07] <hildjj> mbelshe: my sense was he meant we were going to talk about it in a little while here.
[14:24:11] <PHB> mbelshe - should probably add in a section on 'upgrade failure'
[14:24:13] <mbelshe> ok
[14:24:46] <PHB> Upgrade is gonna fail in weird and wonderful ways
[14:25:06] SM leaves the room
[14:25:22] Ben Niven-Jenkins joins the room
[14:25:38] SM joins the room
[14:25:41] <=JeffH> gm @mic: <discussing fine points of upgrade>
[14:26:04] <=JeffH> phb@mic: 1st thing is successful upgrade, 2nd thing is what to do if it fails
[14:26:27] <=JeffH> jhil: is there a timeing issue with expect 100 continue ?
[14:26:56] <=JeffH> mnot: do an upgrade and combine with expectation?
[14:27:04] <=JeffH> roy: wouldn't normally do that
[14:27:38] <=JeffH> roy: the 1st req you make shudn't be a large state changing operation
[14:28:03] <=JeffH> roy: so u send options or GET first (so its not a pkt loss issue)
[14:28:11] <=JeffH> jhil: so perhaps need note about that in spec
[14:28:15] <PHB> No roy - PEOPLE SHOULD do it right, they won't of course
[14:29:16] <hildjj> Note: I'm referring here to 2616, section 8.2.3: "Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect: 100- continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body."
[14:29:38] <=JeffH> mnot: discussion we need to have is whether a upgrade like this is workable for us -- in hybi they figgered that about 70% conns using this would be successful, rest wud fail
[14:29:53] <fielding> you don't upgrade a request while sending a large body and Expect 100-continue -- it is simply not a use case that is relevant. It might work quite well, but it simply isn't worth being concerned about.
[14:30:08] <Eliot Lear> LOL!!
[14:30:12] <=JeffH> mnot: so perhaps deplying using this it'd encourage the internet to upgrade, but only if we have fast failure fallback
[14:30:42] <mbelshe> i don't know why we think a 70% solution would ever be adequate :-)
[14:30:59] <hildjj> fielding: if I just use curl on the command line to send a POST to a network API, would I expect it to do an OPTIONS first?
[14:31:08] <=JeffH> patrick mcmanus (pm) @mic : in FF, doing 6455 (?) the TLS success rates are substantially betterr than the plain success rates
[14:31:28] <=JeffH> roughly 80% with TLS, maybe almost 70% with plain HTTP
[14:31:30] <Eliot Lear> define "success"?
[14:31:36] <fielding> jhildebr, with expect as well?
[14:31:45] hardie@jabber.psg.com leaves the room
[14:31:55] <mbelshe> why only 80% even with tls?
[14:31:58] <Eliot Lear> mic: what did success mean in this case?
[14:32:30] <hildjj> fielding: expect100 seems reasonable, yes. imagine the network API for dropbox, where i'm uploading a file.
[14:32:46] <=JeffH> salvatore@mic: its true we had not so good suc rate with plain upgrade, but lots of boxes will be upgraded, and they (?) just relaeased boxes with spdy support and [we'll see what happens (?)]
[14:32:57] <hildjj> and there may be policy for a max file size, e.g.
[14:33:11] <=JeffH> mnot: <missed it>
[14:33:39] <=JeffH> salvatore: <something about putting proxies in the path (to help out)?>
[14:33:46] <hildjj> sorry, eliot. you still want that?
[14:33:53] <=JeffH> mnot: looking at charter
[14:34:00] <hildjj> i assume they mean they got a full handshake and transmitted data
[14:34:29] <=JeffH> mnot: there'll be several versions of the protocol out there because we're going to try various approaches
[14:36:24] <=JeffH> mnot: the upgrade mech needs certain capabilities, eg supporting opportunistic use of TLS
[14:36:27] <Martin Thomson> for science!
[14:36:41] <Eliot Lear> joe h: nevermind
[14:37:40] <Martin Thomson> salvatore was noting that you can't guarantee the same path for two subsequent requests in some networks, which means that you could encounter an intermediary that doesn't support HTTP2
[14:37:45] <=JeffH> mnot: calling for data on how upgrades are working -- with data we have now, it seems if we design this thing well it';ll either succeed or fail fast ---- wondering about what folks thing whegther we shud go down "this path"
[14:37:46] <Eliot Lear> mic: should pursue this path, but need more data.
[14:37:55] <Eliot Lear> can defer
[14:37:55] <=JeffH> pm: let's talk about the other approached
[14:38:20] <mbelshe> we can keep hoping for the data to change, but don't we already know....
[14:38:39] <=JeffH> mnot: ok, another approach is "Using a SRV (or other DNS) record" (from <http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html>
[14:39:09] Dowon Kim leaves the room
[14:39:17] <=JeffH> mnot: have heard that there is general interest in using DNS as a mech, and do folks think we shudn't use SRV?
[14:39:41] <Eliot Lear> Mic: NOT in favor of SRV.
[14:39:58] <=JeffH> ekr: this is 1st time mention srv, make sure the server id check u do is with name u started with not with the one srv gives u
[14:39:58] <Eliot Lear> Mic: What are the goals? Please be specific!!
[14:40:03] <=JeffH> mnot: yes
[14:40:19] <=JeffH> jeffh: <thinks rfc6125 discusses this>
[14:41:05] <mbelshe> mic: is there a serious proposal around srv? or is this at the brainstorm stage?
[14:41:10] <=JeffH> cyrus d (cd) @mic: i get http://example.com and running http/2 ojn thaqt, but on example.com:88 running http/1 ....
[14:41:28] <=JeffH> pm: if uri contains port, then we're not going to do the srv lookup (?)
[14:41:40] <=JeffH> jhil: channel eliot
[14:42:05] <=JeffH> jhil: <chan mbelshe>
[14:42:07] hardie@jabber.psg.com joins the room
[14:42:11] <=JeffH> mnot: we @brainstorm stage
[14:42:45] EKR joins the room
[14:42:46] <=JeffH> jhil: 1) agree ekr, but if dnssec signed, u might b able to use 2nd name (2) <missed it>
[14:42:51] <Eliot Lear> thanks, joe!
[14:43:11] <cyrusdaboo> Maybe it is possible to encode a port into the SRV lookup: e.g. http://example.com:8080, because 8080._http2._tcp.example.com <http://tcp.example.com>?
[14:43:20] <hildjj> cyrusdaboo: ew.
[14:43:32] <Eliot Lear> cyrus: ew as well. but there's another problem:
[14:43:38] john joins the room
[14:43:39] <mbelshe> would like to see a fully baked proposal before discussing here.
[14:43:41] <Eliot Lear> the SRV zone cut can induce delay
[14:43:47] <Eliot Lear> mbelshe: +1.
[14:43:50] <hildjj> i see your point better now, though
[14:44:32] <=JeffH> phb@mic: the dns is where u make assns re names; shud bind names & prots "in dns"; there's prac issues with doing this; in how clients use dns; don't nec use srv; want to use dnssec; so going to use "new dns" world anyway; and so may want srv+ <eg need to invent new dns stuff>
[14:44:53] <PHB> +Eliot, not if you do it right
[14:45:19] <PHB> People who really care are going to optimize their connections
[14:45:27] <Eliot Lear> PHB: we live in the real world: there are other SRV records, and because of existing deployments there are going to be zone cuts
[14:45:38] <Eliot Lear> that means that Additional Information is suspect or useless
[14:45:42] <hardie@jabber.psg.com> The only way SRV/NAPTR/URI RR work is if you can distinguish between the services; a bare port not associated with an independent service is going to be really difficult to differentiate. But you could make http and http2 as different services. (pointer to the URI RR for those who haven't seen it: http://tools.ietf.org/html/draft-faltstrom-uri-06)
[14:45:50] <PHB> But we are designing for the world in 4+ and 10+ years time
[14:46:04] <PHB> We should be telling people how to do the job right
[14:46:13] <=JeffH> pm: this is more work everywehre, u can set this up; and so in one round trip get all info u need, can mux with this btwn http 1 & 2 and whatever, <missed stuff> so this approach gives some nice benefits
[14:46:13] <Eliot Lear> but the right job may not be with SRV
[14:46:23] <Eliot Lear> especially if we're talking 4+ years from now
[14:46:27] Dowon Kim joins the room
[14:46:39] <Eliot Lear> so, phb, i agree with your separation of tasks
[14:46:39] <=JeffH> ? @mic: if u get a diff port from srv, do you use that?
[14:46:39] <PHB> Agreed, SRV+ is likely a better plan
[14:47:01] <=JeffH> mnot: there's a lot sec related concerns here need to be careful
[14:47:11] <Eliot Lear> this is why gabriel's draft is important
[14:47:34] <PHB> But the first commitment is whether to use the DNS at all
[14:47:46] <Eliot Lear> can do both!!
[14:47:51] <=JeffH> eric nigren (en): having srv records wud be advantag; addtnl bennie is having sep servers handling http/1 and http/2 -- help deployment
[14:48:10] <fielding> Folks have to keep in mind that a typical server machine contains numerous HTTP servers (multiple port listeners) for such things as IPP, network management, etc.
[14:48:22] <Eliot Lear> roy: +1
[14:48:24] <=JeffH> mnot: inclined to say this (srv/dns stuff) will be a work item for us
[14:48:47] <PHB> +Roy which is one of the reasons why SRV like mechanism is needed
[14:49:06] <=JeffH> mnot: upgrade mech shud start in main draft
[14:49:09] <mbelshe> i don't think this is a serious proposal without a implementation.
[14:49:13] <PHB> If someone is doing a Web service it should probably have a different SRV tag
[14:49:15] <hardie@jabber.psg.com> IPP, NMS, etc. are independent servcies from an SRV/NAPTR/URI point of view, so that's relatively speaking easy to distinguish—modulo some increase in the number of _name records.
[14:49:16] <mbelshe> or at least a writeup
[14:49:19] <=JeffH> ... this dns mech stuff in sep draft perhaps
[14:49:29] <Martin Thomson> DDDS is probably overkill
[14:49:36] <Eliot Lear> mike, what's your proposal here?
[14:49:55] <hardie@jabber.psg.com> @Martin it's certainly not going to be quick in the general case.
[14:49:56] danwing leaves the room
[14:49:57] <=JeffH> ...3d mech " 2) Using a response header to hint that HTTP/2 is available on another port" from <http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html>
[14:49:57] <PHB> I like SRV and URI records because they are simple. I would be OK with extra fields if justified
[14:50:03] <PHB> I really hatre NAPTR
[14:50:16] <Eliot Lear> ted: there are still often many different http servers running on different ports of the same host
[14:50:17] <mbelshe> i'm not proposing we do anything with dns right now. if a champion wants to step up and try it, maybe there will be something to talk about next time. but if not, lets move on.
[14:50:25] <=JeffH> roberto: <comment about upgrade detail>
[14:50:26] <Eliot Lear> NAPTR: The SNOBOL of DNS
[14:50:59] =JeffH leaves the room
[14:51:01] <Eliot Lear> mike, thanks, but are you suggesting to move forward with what Gabriel's proposal?
[14:51:03] EKR leaves the room
[14:51:44] <Eliot Lear> Pursue both for now.
[14:51:48] <mbelshe> abstaining for the moment.
[14:51:58] <PHB> Eliot, NAPTR is the INTERCAL of DNS
[14:52:55] EKR joins the room
[14:53:45] <Martin Thomson> enumeration is: TLS nextproto, HTTP upgrade, srv or other DNS record, alternate-protocol header
[14:53:54] <hillbrad> mnot: start developing DNS based, and a response header based mechanism as well
[14:54:20] <hillbrad> mnot: selected editors for core HTTP work, Martin Thompson, Aleksy Melnikov, and Julian Resshke will be helping out
[14:54:25] <hildjj> If this isn't *just* for http:, you might also put a hint in the server cert?
[14:54:25] <Eliot Lear> I volunteer to develop at least one DNS-based proposal
[14:54:33] <hillbrad> mnot: don't want to put all work on them
[14:55:11] <hildjj> (just brainstorming other possibilities, don't actually think that's useful)
[14:55:14] <fielding> FTR, I don't think any of these mechanisms are a blocker for deploying a new version of HTTP. We are not talking about an experiment or a local hack. If a few implementations have bugs, they will be identified and replaced.
[14:55:18] <hillbrad> mnot: all we have for upgrade based topic
[14:55:25] <hildjj> fielding: +1
[14:55:45] <hillbrad> mnot: next topic, header compression
[14:55:46] tony.l.hansen leaves the room
[14:56:25] <hillbrad> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HTTP2Compression
[14:56:35] tony.l.hansen joins the room
[14:57:50] <hillbrad> Herve Ruellan slides on HTTP Header Encoding Results
[14:57:52] <hildjj> http://www.ietf.org/proceedings/85/slides/slides-85-httpbis-1.pdf
[14:59:44] rch joins the room
[15:01:00] =JeffH joins the room
[15:02:31] rch leaves the room
[15:02:53] <=JeffH> <I'm bk online apres net difficulties>
[15:03:25] <=JeffH> on the slide: compression results No Deflate
[15:03:40] <=JeffH> next slide: comp results with deflate (slide 5)
[15:03:49] EKR leaves the room
[15:04:20] rch joins the room
[15:05:02] <=JeffH> jhil: think about impact on mobile devices such as pwr requied ?
[15:05:21] <mbelshe> is there awareness about the security bug in spdy3 compression? and are these algorithms equal?
[15:05:26] <=JeffH> agl @mic: so now spdy compression has issues with trying to avoid crime attack
[15:05:29] <mbelshe> (don't mix user data with cookies, basically)
[15:05:36] <=JeffH> rp: but its still useful as baseline
[15:05:39] <rch> agl just mentioned that
[15:05:43] <mbelshe> ah - agl got it
[15:05:46] <mbelshe> :-)
[15:06:15] <hildjj> mbelshe: do you have a pointer to that security issue handy so i can read about it later?
[15:06:23] <=JeffH> slide 6 efficient tools for header value encoding
[15:06:53] <rch> hildjj: http://zoompf.com/2012/09/explaining-the-crime-weakness-in-spdy-and-ssl
[15:07:04] <hildjj> rch: thx
[15:07:14] Joe Gregorio joins the room
[15:07:28] <=JeffH> slide: summary
[15:08:05] <=JeffH> back to mnot
[15:08:27] <=JeffH> see github.com/http2/http_samples
[15:08:37] <=JeffH> this is corpus of header samples
[15:08:39] <hildjj> oh, right. i do remember reading about this attack.
[15:09:27] <=JeffH> have har files from pcap capture
[15:09:33] <=JeffH> captures
[15:10:11] <=JeffH> if can get more folks submitting such,then we have good data to work with
[15:10:19] <=JeffH> cd: what about webdav et al?
[15:10:27] <=JeffH> mnot: if u wanna submit traces for that pls do
[15:10:41] <PHB> I am MUCH less interested in the compression efficiency of the mechanism chosen as the memory requirements, CPU impact and complexity of coding.
[15:10:42] <=JeffH> ...also will do api use of http
[15:11:01] <PHB> Debugging a compression library and a protocol at the same time is not my idea of fun
[15:11:21] <=JeffH> jhil: prob need some enterprise traces cuz of strange cross-domain cookies we see, but need to anon them
[15:11:34] <=JeffH> mnot: but not concerned about pathalogical cases
[15:11:41] <Eliot Lear> if the enterprise use case is pathological, then that's a whole lot of pathological use cases.
[15:11:46] <=JeffH> jhil: but might help show which compress scheme is better
[15:12:19] <hildjj> eliot: i got that point across with the look on my face, I think. :)
[15:12:35] <=JeffH> mnot: nxt thing come up with script that analyses this stuff, and eg can emit a pathological case, and then run compression algs on it and see how it works
[15:13:14] <=JeffH> rp: can do this in python & work with mnot
[15:14:47] <=JeffH> roy: http2 is not a minor hack -- need to do it carefully -- perhaps we shud have better encoding for header fields, eg cookies are huge, this could be binary, if we define an encoding, then can encode cookies when sending over http and get diff comp results
[15:15:25] <=JeffH> mnot: thks we can define new headers that have diff encodings eg binary, and then downgrade them to eg txt when sending over http/1
[15:16:23] <=JeffH> roy: a cook header field, obviously can't change that due to existing brwosers, but browsers jsut store it and replay it; new thing doesn't have to be compat with existing cookies, so if svr has choice to send short cook rather than long one....
[15:17:19] <=JeffH> mnot: two diff things here, one is http1 <-- > http/2 <--> http/1 w/o loss
[15:17:52] <=JeffH> ... the other is doing stuff in http/2 that are new ( and then needing to downgrade new stuff into http/1 as nec )
[15:17:58] <PHB> +1 Roy And fix some of the privacy issues with cookies at the same time
[15:18:11] <PHB> Cookie stealling does not need to be possible
[15:18:23] <=JeffH> mnot: back to github corpus
[15:18:26] <=JeffH> of headers
[15:18:34] <hildjj> e.g. we could say you base64-encode these headers when they go over http1 channels.
[15:20:08] <=JeffH> mnot: if u can compress a bunch of requests down to fit in one underlying pkt, then that's very powerful, esp in mobile world
[15:20:32] <=JeffH> ...inclined to keep that in mind when selecting compressn approach
[15:20:46] <=JeffH> ....need to keep memory & cpu & pwr overheads in mind
[15:21:09] fenton leaves the room
[15:23:02] <=JeffH> rp @mic: web app dvlps shudn't have to opt their site to "make it fast" -- rather shud make prot fast
[15:23:08] <=JeffH> mnot: yes
[15:23:24] <=JeffH> phb: what about patent issues in compression?
[15:23:36] <=JeffH> mnot: they'll have to disclose
[15:23:51] <=JeffH> phb: if u make disclossure call now it has implications down the road
[15:24:02] <=JeffH> mnot: we'll deal iwth that later
[15:24:22] <PHB> Unencumbered is basically going to restrict people to 20 year old algorithms
[15:24:36] <=JeffH> mnot: we prob won't choose perfect comp mech for all time, thus negotiate comp mech?
[15:25:05] <Martin Thomson> the web will change, such that any choice that we make might be invalidated at any time
[15:25:09] <=JeffH> mnot: if upgrade mech is adequate, then can include comp mech in that, but if too much optionality there, that's interop probs
[15:25:11] <PHB> New stuff is just not going to be viable no matter what the proposer says about their claims, they can't know who else will make claims
[15:25:45] <=JeffH> mnot: wud be nice if can put it into debug mode to see stuff on wire -- so question to be able to turn comp on/off ?
[15:25:52] <=JeffH> ....thots on this?
[15:26:00] danwing joins the room
[15:26:49] <=JeffH> rp: perhaps can put stuff in there to make debugging "easy" rather than "turn it off"
[15:28:01] mbelshe leaves the room
[15:28:18] <=JeffH> mnot: roberto wants to talk about http/w compression
[15:28:37] <=JeffH> rp: slide 1
[15:28:50] <=JeffH> problems with currently deployed gzip comp
[15:29:41] <=JeffH> slide 2: how it works
[15:30:18] <hildjj> http://tools.ietf.org/html/draft-rpeon-httpbis-header-compression-00
[15:30:29] <=JeffH> slide 3: more details
[15:30:51] EKR joins the room
[15:31:02] <=JeffH> slide 4: yet more
[15:31:59] <=JeffH> slide 5: how well does this work?
[15:33:28] <=JeffH> ...depending on gzip window size, its roughly the same or better than gzip
[15:33:42] <=JeffH> slide 6: how well cont'd
[15:33:56] <=JeffH> ....AFACT is not vuln to crime exploit
[15:34:04] <rch> (roughly same compression, but 1/3 the CPU)
[15:34:09] <=JeffH> slide 7: disadvantages
[15:34:20] <=JeffH> ....doesnt achieve max possible compress ration
[15:34:28] <=JeffH> s/ration/ratio/
[15:35:29] <hildjj> roy said "yes, the compression ratio gets better if you send garbage on the wire"
[15:35:34] <=JeffH> [ this is a "delta coder" ]
[15:35:52] <=JeffH> rp: said that those garbage bytes don't actually end up on the wire
[15:36:06] <=JeffH> slide 8: advantges of the compressor
[15:36:14] <PHB> I like the delta encoder a lot more than gzip. I really do not like Gzip
[15:36:31] <=JeffH> ....fast, and proxy-friendly
[15:36:46] <=JeffH> slide 9 advantages contd
[15:37:17] <=JeffH> ....has a dont-compress mech that can be useful for debugging
[15:37:26] <=JeffH> slide 10: advant contd
[15:38:17] <=JeffH> slide 11: advantag contd
[15:38:33] <=JeffH> slide 12: avenues of further reseach
[15:39:08] <=JeffH> slide 13: cont
[15:39:09] <=JeffH> 'd
[15:39:41] <=JeffH> <done>
[15:39:59] <=JeffH> roy: notes that a fixed id space is essentially a registry in machine readable form
[15:40:03] <=JeffH> rp: yes
[15:40:16] tony.l.hansen leaves the room
[15:40:23] <=JeffH> but its not a reg that needs to be maintained after its created
[15:40:44] <=JeffH> martin thompson (mt): dont understand where huffman encoding comes into play?
[15:41:22] <=JeffH> rp: draft needs work; what is huffman coded is the text in the headers
[15:41:30] tony.l.hansen joins the room
[15:41:51] <=JeffH> rp: ran analysis over sample of headers, and then used that to gen id space
[15:41:54] <PHB> seems to me that we are maybe doing this the wrong way
[15:42:13] <=JeffH> rp: hopefully impl code for this is better to understand than the I-D at this point :)
[15:42:25] <PHB> The server delivers an HTML text with links, then the client chooses links to resolve
[15:42:49] <PHB> So can't we just compress the list of links to sent from server to client to a bit string?
[15:43:05] <=JeffH> mnot: so we know sorta where we going on compession stuff, want to get impls plugged into the http2 namespace on github -- the more visible we can make this the better
[15:43:27] <Martin Thomson> the question was: do you have a note well on the repo
[15:43:41] <=JeffH> mnot: next..... server push issue #387
[15:44:06] Eliot Lear leaves the room
[15:44:18] <PHB> If the links in the docukment are x.gif, y.gif z.gif and the client already has y then it would sent the bit stream 00000101 or 05H There, just compressed the HTTP headers to one byte
[15:44:35] <=JeffH> .... -00 WG draft will be cleaned up spdy proposal and thus will have svr push in it
[15:45:02] <=JeffH> ...questionsn are what we do with it afterwards, but we're not sure at this point? <no comments, so punt for now>
[15:45:19] <=JeffH> mnot: so, next..... any other issues to bring up at this point?
[15:46:14] <=JeffH> mnot: what else needs to be in draft that isn't in there -- bring up issues -- can spend 30 min on that now -- - eg flow control --- and then at end 10 min on nxt steps to keep work moving
[15:47:08] <=JeffH> ... so, flow control -- gabriel montenegro (gm) -- flow ocntrol principles for http 2
[15:47:15] <=JeffH> slide 1: flow control in http2
[15:48:37] danwing leaves the room
[15:48:47] <=JeffH> ....goal: explicitly decouple flow control principles from the many possible algs
[15:49:37] <=JeffH> slide 2: principles for flow cntl
[15:49:50] <=JeffH> FC == flow cntl
[15:51:14] <hildjj> we need TSV help for this part.
[15:51:34] <=JeffH> .... seeking to gain agreement on set of FC principles
[15:53:54] <=JeffH> [ TSV == transport area folk ]
[15:54:02] <=JeffH> gm: slides over, thots ?
[15:54:28] <=JeffH> roy: init exchg over tcp, client begins; with this do you expect server to send anything first wrt state?
[15:54:52] <=JeffH> gm: in spdy there's default 64k per stream
[15:55:42] <=JeffH> rp: basically need default for safety reasons, but a better FC mech than spdy3 exists, hopefully will be propsed, can make larger than 64k by defualt
[15:56:01] <=JeffH> ted hardie(th): what impact if doing multipath tcp under this?
[15:56:42] <=JeffH> gm: yes need to figure out interaction with newish tcp stuff under it
[15:57:22] <=JeffH> mnot: is FC tightly bound to what xport's properties are?
[15:57:24] <=JeffH> gm: yes
[15:57:29] <=JeffH> rp: <nods yes>
[15:57:35] EKR leaves the room
[15:57:48] <=JeffH> jhil: we need early involvement by transport folks, don't wanna make buffer bloat worse
[15:57:54] <=JeffH> rp: don't think that's possible
[15:57:55] EKR joins the room
[15:58:04] <Martin Thomson> buffer bloat!
[15:58:51] <=JeffH> will chan (wc): wud hope that FC in http/2 doesn't subvert xport FC; want to make sure we saturate link; this shud be one of the principles
[16:00:07] <=JeffH> gm: thinks link saturation depends on how the <sliding window / credits > work; don't havew to solve now
[16:00:08] <hildjj> rp is convincing that this doesn't make bufferbloat worse, but we agreed that we need real TSV expertise to ensure that we know what we're doing.
[16:00:38] <=JeffH> alison mankin (am): if receiver has FC turned off by intermed, that messes stuff up;
[16:00:54] <=JeffH> gm: but receiver controls it for his hop
[16:01:10] <=JeffH> am: is concerned about middleboxes at http layer
[16:01:24] <=JeffH> gm: at that layer the proxie has to heed what endpoint (receiver) wishes
[16:01:45] <=JeffH> am: still concerned on traps that may be there
[16:02:30] <=JeffH> rp: there's finite buffering available for entire path length; if receiver says stop, it'll stop eventually; but as soon as an intermediate is in the path, they have influence on FC
[16:02:40] <=JeffH> gm: we need to codify the rules in the base spec
[16:03:05] <=JeffH> mnot: gm will have draft coming out, please review
[16:03:22] <=JeffH> mnot: FC will get a new issue #
[16:03:32] <=JeffH> mnot: any other issues to discuss here?
[16:03:52] <=JeffH> pm: priorities need disc
[16:04:14] <=JeffH> mnot: will create issue for that (framing, diff frame sizes)
[16:04:41] <=JeffH> rp: want to agree and disagree wrt priortzn stuff -- need more experimentaiton
[16:05:05] <=JeffH> mnot: sure, may defer disc of these issues, but want to get em written down
[16:05:35] <=JeffH> eric nygren (en): mapping to tcp -- need to disc
[16:05:48] <=JeffH> mnot: yes, need optional draft on "how i use tcp"
[16:06:08] <=JeffH> rp: agree with en that'll be issue, might wanna address earlier, need to get sec folk thinking about that
[16:06:30] <=JeffH> en: also has implications for prot upgrade mech, signaling may make this easier or harder
[16:07:03] <=JeffH> gm: did u raise issue on framing itself?
[16:07:29] <=JeffH> mnot: it will get raised; specif concern, is if i send a big file, i can get big frames
[16:09:09] <=JeffH> mnot: am gratified to see folks working on drafts; continue doing that; will use wiki to record current state of proposals; interlink to issue #s; will also use github; will hand out access to (sub) repositories; the actual drafts will be in ietf subversion service;
[16:09:14] EKR leaves the room
[16:10:26] <=JeffH> mnot: f2f meetings are effective for work like this, involves lots of folks, need to confirm decsions on list, tho possiblities of interim meetings, may be good idea here in earlier phase like this,
[16:10:47] <=JeffH> current plan is interim mtg in Jan 2013, 2..3 days,
[16:11:34] <=JeffH> ...offer from Ian Fette to host in Tokyo, need to get dates, maybe mid Jan to early Feb, pls send dates ideas to mnot
[16:11:58] <=JeffH> mnot; any more biz ?
[16:13:18] <=JeffH> phb: discussing compressoin -- was of msgs, not conversations -- in mobile -- sending "pages" with lists of links --- but maybe do html-conscious compression ?
[16:13:26] <=JeffH> rp: <explained>
[16:13:37] <=JeffH> jhil: don't we get some of thiaqt with svr push?
[16:13:51] EKR joins the room
[16:14:08] Dowon Kim leaves the room
[16:14:14] <=JeffH> en: if start with http1, include an encoded blob of handshake frameing ?
[16:14:42] <=JeffH> mnot: that's in category of cool tricks we could play.....
[16:14:53] hardie@jabber.psg.com leaves the room
[16:14:56] PHB leaves the room
[16:15:15] Eliot Lear joins the room
[16:15:17] <=JeffH> ....keep drafts coming, will send minutes out soon, if hold this interim mtg, want to make it useful
[16:15:24] <=JeffH> adjourned !!
[16:15:26] Ken Murchison leaves the room
[16:15:32] <Eliot Lear> thanks jeffh!!!
[16:15:32] rch leaves the room
[16:15:35] m&m leaves the room: Disconnected: connection closed
[16:15:43] Eliot Lear leaves the room
[16:15:45] hildjj leaves the room
[16:15:48] hillbrad leaves the room
[16:15:50] cyrusdaboo leaves the room
[16:15:51] SM leaves the room
[16:15:52] Martin Thomson leaves the room
[16:16:02] <bkihara> Thank you =JeffH!!
[16:16:02] Atarashi Yoshifumi leaves the room
[16:16:02] msk leaves the room
[16:16:02] Ben Niven-Jenkins leaves the room
[16:16:07] fielding leaves the room
[16:16:09] tfossati leaves the room
[16:16:11] lef.jpn leaves the room
[16:16:33] kazubu leaves the room
[16:17:23] frodek leaves the room
[16:17:48] julian leaves the room
[16:18:16] =JeffH leaves the room
[16:20:11] yuioku.yj leaves the room
[16:20:29] bkihara leaves the room
[16:21:07] joseph.yee leaves the room
[16:22:28] EKR leaves the room
[16:27:54] Ken Murchison joins the room
[16:28:03] Ken Murchison leaves the room
[16:28:32] cabo leaves the room
[16:31:21] barryleiba leaves the room
[16:32:41] Gabriel Montenegro leaves the room
[16:32:50] john leaves the room
[16:34:02] stpeter leaves the room: Disconnected: connection closed
[16:38:45] Joe Gregorio leaves the room
[16:38:51] cabo joins the room
[16:49:32] xiaohong.deng leaves the room
[16:55:34] Ben Niven-Jenkins joins the room
[16:58:30] xiaohong.deng joins the room
[17:17:07] EKR joins the room
[17:18:46] lef.jpn joins the room
[17:32:14] kazubu joins the room
[17:34:09] hardie@jabber.psg.com joins the room
[17:34:13] hardie@jabber.psg.com leaves the room
[17:38:29] kazubu leaves the room
[17:38:30] kazubu joins the room
[17:44:06] lef.jpn leaves the room
[17:48:48] john joins the room
[17:49:22] cyrusdaboo joins the room
[17:50:30] cabo leaves the room
[17:54:39] rch joins the room
[17:55:09] cabo joins the room
[17:55:11] hillbrad joins the room
[17:56:52] rch leaves the room
[17:58:54] hillbrad leaves the room
[17:59:00] Ben Niven-Jenkins leaves the room
[18:01:30] xiaohong.deng leaves the room
[18:01:59] lef.jpn joins the room
[18:02:03] xiaohong.deng joins the room
[18:02:05] tony.l.hansen leaves the room
[18:02:12] EKR leaves the room
[18:02:21] joseph.yee joins the room
[18:03:11] msk joins the room
[18:03:14] m&m joins the room
[18:03:18] m&m leaves the room
[18:04:30] kazubu leaves the room
[18:04:37] kazubu joins the room
[18:04:47] kazubu leaves the room
[18:06:07] xiaohong.deng leaves the room
[18:06:22] hildjj joins the room
[18:09:41] EKR joins the room
[18:12:47] hildjj leaves the room
[18:30:16] msk leaves the room
[18:35:53] EKR leaves the room
[18:43:53] EKR joins the room
[18:52:15] EKR leaves the room
[19:03:17] EKR joins the room
[19:07:36] Ben Niven-Jenkins joins the room
[19:12:46] danwing joins the room
[19:13:26] danwing leaves the room
[19:27:16] EKR leaves the room
[19:28:45] EKR joins the room
[19:29:32] EKR leaves the room
[19:41:58] lef.jpn leaves the room
[19:48:31] Ben Niven-Jenkins leaves the room
[19:55:14] joseph.yee leaves the room
[19:58:01] cabo leaves the room
[19:58:02] cabo joins the room
[20:01:19] cyrusdaboo leaves the room
[20:04:24] Ben Niven-Jenkins joins the room
[20:07:41] cabo leaves the room
[20:13:19] cyrusdaboo joins the room
[20:18:42] john leaves the room
[20:18:44] john joins the room
[20:21:00] lef.jpn joins the room
[20:28:48] cabo joins the room
[20:35:16] joseph.yee joins the room
[20:59:19] EKR joins the room
[21:01:36] EKR leaves the room
[21:02:48] EKR joins the room
[21:12:54] EKR leaves the room
[21:46:42] lef.jpn leaves the room
[21:53:08] cyrusdaboo leaves the room
[21:55:43] cabo leaves the room
[21:58:41] lef.jpn joins the room
[21:59:34] cyrusdaboo joins the room
[22:00:26] joseph.yee leaves the room
[22:04:13] Ben Niven-Jenkins leaves the room
[22:04:45] EKR joins the room
[22:07:02] john leaves the room
[22:07:18] cabo joins the room
[22:18:41] john joins the room
[22:34:45] Ben Niven-Jenkins joins the room
[22:36:43] Ben Niven-Jenkins leaves the room
[22:42:25] EKR leaves the room
[22:49:48] EKR joins the room
[22:56:56] cabo leaves the room
[22:58:43] joseph.yee joins the room
[22:58:58] EKR leaves the room
[23:06:54] Ben Niven-Jenkins joins the room
[23:07:15] EKR joins the room
[23:08:34] EKR leaves the room
[23:10:23] EKR joins the room
[23:10:43] Ben Niven-Jenkins leaves the room
[23:24:06] lef.jpn leaves the room
[23:24:41] EKR leaves the room
[23:26:18] john leaves the room
[23:27:25] lef.jpn joins the room
[23:28:14] lef.jpn leaves the room
[23:28:20] cyrusdaboo leaves the room
[23:33:45] joseph.yee leaves the room
[23:35:42] lef.jpn joins the room
[23:36:49] lef.jpn leaves the room
[23:41:21] Ben Niven-Jenkins joins the room
[23:45:40] lef.jpn joins the room
[23:55:24] joseph.yee joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!