IETF
tcpm@jabber.ietf.org
Wednesday, 16 November 2011< ^ >
jishac has set the subject to: TCP Maintenance and Minor Extensions WG
Room Configuration

GMT+0
[00:23:29] Michael Scharf leaves the room: Replaced by new connection
[00:23:30] mscharf joins the room
[00:56:37] jlcJohn joins the room
[01:02:47] wesley.m.eddy joins the room
[01:03:18] jana.iyengar joins the room
[01:04:16] <mscharf> (Remote) greetings to all!
[01:04:38] <wesley.m.eddy> hi; I'm the jabber person, since I think nobody else from the room is on
[01:04:53] <wesley.m.eddy> Yoshifumi has just started the meeting, in case you can't hear or there is lag; we're on the agenda
[01:05:11] <mscharf> audio works well
[01:05:23] <jana.iyengar> yup, all's well
[01:05:39] <wesley.m.eddy> slide: recent rfcs
[01:05:45] <wesley.m.eddy> slide: items nearing rfc
[01:08:04] <wesley.m.eddy> slide: active WG items
[01:08:12] <wesley.m.eddy> lars had comment on how we can make 1323bis go faster
[01:08:13] <mscharf> david promised to complete the two drafts soon
[01:08:23] tplunke\40jabber.org joins the room
[01:08:30] <wesley.m.eddy> tcpsecurity
[01:09:05] <wesley.m.eddy> lars at mic
[01:09:13] <wesley.m.eddy> agrees that we don't need to decide now
[01:09:17] <wesley.m.eddy> one option is to drop work item
[01:09:43] <wesley.m.eddy> joe touch asking if we know what needs to be done
[01:10:12] <wesley.m.eddy> asks if there's a shopping list of what needs to be done
[01:10:19] <wesley.m.eddy> if there isn't one, we can't do anything for now
[01:11:00] <wesley.m.eddy> next slide: active WG items
[01:11:50] <wesley.m.eddy> no items under poll to become WG item
[01:11:57] <wesley.m.eddy> see mailing list for summary
[01:12:37] touch joins the room
[01:12:52] <wesley.m.eddy> matt on proportional rate reduction
[01:13:19] <wesley.m.eddy> slide: we want to improve tcp recovery
[01:15:52] <wesley.m.eddy> slide: standard tcp fast recovery
[01:18:49] <wesley.m.eddy> slide: working from first principles
[01:21:16] <wesley.m.eddy> slide: when losses exceed CC reduction
[01:22:00] <wesley.m.eddy> slide: PRR with slowstart bound
[01:22:51] <wesley.m.eddy> slide: prr properties
[01:23:30] <wesley.m.eddy> slide: prr results
[01:24:43] <wesley.m.eddy> slide: onward
[01:24:54] <wesley.m.eddy> (matt seems to be missing a slide on "india data" - see imc paper)
[01:26:01] <mscharf> the slide deck on the material page contains that slide
[01:26:03] <wesley.m.eddy> no questions
[01:26:23] <wesley.m.eddy> slide: post script
[01:27:34] <wesley.m.eddy> lars at mic
[01:27:38] <wesley.m.eddy> joe behind him
[01:27:44] <wesley.m.eddy> suspects transparent web proxies
[01:28:04] <wesley.m.eddy> data covers all ports on all google services
[01:28:17] <wesley.m.eddy> joe touch: sounds more like nat lost state and not sending rst
[01:28:37] <wesley.m.eddy> BEHAVE doc talks about NAT reqs (long time ago)
[01:29:13] <wesley.m.eddy> from public side NAT must act like host; not router, must send RST
[01:29:23] <wesley.m.eddy> 5382 is the RFC
[01:29:48] jana.iyengar leaves the room
[01:29:50] <wesley.m.eddy> should have been more specific
[01:30:05] <wesley.m.eddy> lars agrees, but disagrees that BEHAVE is the problem .. no vendor implements those specs
[01:30:33] <wesley.m.eddy> matt says they *could* get into name calling ;)
[01:30:39] <wesley.m.eddy> but don't want to
[01:30:50] <wesley.m.eddy> someone volunteers to in audience
[01:31:03] <wesley.m.eddy> joe wants to know if it's a datacenter, isp, phone company, etc
[01:31:14] <wesley.m.eddy> matt: most likely a nat and nobody even knows it
[01:31:55] <wesley.m.eddy> piers o'hanlon: curious how long these last
[01:32:08] <wesley.m.eddy> matt: hard to say, on order of 6 re-tx
[01:32:17] <wesley.m.eddy> jerry chu up
[01:32:40] <wesley.m.eddy> TCP fast open draft revision
[01:33:05] <wesley.m.eddy> messing with wireless mic
[01:33:15] <wesley.m.eddy> can you hear?
[01:33:35] <wesley.m.eddy> agenda slide
[01:33:39] <jlcJohn> (no audio problems...
[01:33:51] <mscharf> No audio currently, but anyway there is a significant delay lag
[01:34:04] <wesley.m.eddy> ok; I wasn't sure if jerry's voice is hitting the mic
[01:34:32] <wesley.m.eddy> slide: draft changes
[01:39:13] <wesley.m.eddy> slide: performance numbers
[01:40:59] <wesley.m.eddy> joe touch: is this related to graph just posted?
[01:41:01] <wesley.m.eddy> YES
[01:41:54] <wesley.m.eddy> joe came up with opposite conclusion; although many connections eligible, only some could be sped up, and then only some phase, not whole thing
[01:42:13] <wesley.m.eddy> in the case of long RTT, page load savings 200ms
[01:42:25] <wesley.m.eddy> not much of the total
[01:44:08] <wesley.m.eddy> slide: persistent http
[01:45:02] <wesley.m.eddy> joe at mic
[01:45:45] <wesley.m.eddy> have to modify client and server; should do same test with persistent connections on, and flushing cache, so assume stays open for all components of page
[01:45:58] <wesley.m.eddy> jerry said default is on
[01:46:04] <wesley.m.eddy> joe: not what I'm saying
[01:46:15] <wesley.m.eddy> jerry: comparing benefit ON TOP of phttp
[01:46:29] <wesley.m.eddy> joe: did you see persistent happening?
[01:46:33] <wesley.m.eddy> jerry: we can check
[01:46:45] <wesley.m.eddy> jerry: tuning problem may not be fixable
[01:46:56] <wesley.m.eddy> matt: step 1 - fix reasons that pervent phttp from being deployed
[01:47:14] <wesley.m.eddy> we try to turn it on as much as we can, but it doesn't get used
[01:47:24] <wesley.m.eddy> jerry: have no control of middlebox
[01:47:30] <wesley.m.eddy> matt: could for purposes of experiment
[01:48:04] <wesley.m.eddy> slide: persistent http (cont)
[01:49:26] mattmathis joins the room
[01:51:10] <wesley.m.eddy> slide: next steps
[01:51:28] <mscharf> @Wes: When it comes to the discussion of WG adoption, please raise the question what the WG thinks about the changed TCP semantics
[01:51:54] <mattmathis> Explain better please
[01:52:06] <wesley.m.eddy> questions?
[01:52:40] <mscharf> Draft: "accept old SYN packets with data"
[01:53:08] <wesley.m.eddy> counting hands
[01:54:26] <wesley.m.eddy> michael - I asked; joe says we had a lot of comments on that already
[01:54:38] <wesley.m.eddy> joe on shared use of TCP experimental options
[01:54:46] <wesley.m.eddy> slide: summary
[01:56:12] <wesley.m.eddy> slide: tcp exp options
[01:56:22] <wesley.m.eddy> slide: tcp experiments
[01:57:50] touch leaves the room
[01:58:02] <wesley.m.eddy> lars: corrects DS to STd Track
[01:58:27] <wesley.m.eddy> slide: approaches to increased experiments
[01:59:15] <wesley.m.eddy> slide: problems with existing approaches
[01:59:38] <wesley.m.eddy> slide: proposed shared use of tcp exp options
[02:01:37] <wesley.m.eddy> slide: properties of this proposed solution
[02:02:01] <wesley.m.eddy> slide: issues
[02:03:41] <wesley.m.eddy> slide: possible extensions
[02:04:27] <wesley.m.eddy> questions?
[02:04:32] <wesley.m.eddy> some people going to mic
[02:04:50] <wesley.m.eddy> jerry chu: sent email and brought up in tsvwg
[02:04:58] <wesley.m.eddy> bcp vs std
[02:05:42] <wesley.m.eddy> matt: could be implementer's agreement
[02:06:52] <wesley.m.eddy> padding with constant data could be at any offset (lower probability of error if at beginning)
[02:07:17] <wesley.m.eddy> problem with existing process is no way to recall numbers
[02:08:06] <wesley.m.eddy> jerry says it could be used for tfo
[02:08:07] <wesley.m.eddy> tero thinks allocating completely new option may be better
[02:08:24] <wesley.m.eddy> suggests adding one new one that requires this
[02:08:40] <wesley.m.eddy> could make smaller number with FCFS
[02:09:27] <wesley.m.eddy> brian something: think it's a cool idea, new number ore structure in magic area would be good
[02:10:04] <wesley.m.eddy> tim shepard: thinks tero has it right
[02:10:56] <wesley.m.eddy> basically a 3-byte option number
[02:11:08] <wesley.m.eddy> problem of running out of space ... 4 extra bytes
[02:12:12] <wesley.m.eddy> mathis: should do both
[02:13:22] <wesley.m.eddy> recommended use of existing should be to use this, and should get 2 new numbers to require this, and people should declare their usage on TCPM list!
[02:13:23] <wesley.m.eddy> joe: don't need to create a new solution
[02:13:28] <wesley.m.eddy> matt: sending note to TCPM not hard
[02:13:33] <wesley.m.eddy> lars/tim: do both!
[02:14:20] <wesley.m.eddy> lars: one case; what would make me ever migrate to normal option; would need to check both cases
[02:14:56] <wesley.m.eddy> matt: completely agree with lars; lifecycle management for options should be another document
[02:15:05] <wesley.m.eddy> have to expect code will support 2 versions
[02:15:11] <wesley.m.eddy> code should have calendars to deprecate
[02:15:19] zcao joins the room
[02:15:25] <wesley.m.eddy> matt has used a recycled codepoint after TALKING to everyone who'd used it
[02:17:19] <wesley.m.eddy> dozen or more think it should adopt
[02:17:52] <wesley.m.eddy> for should not adpot: nobody
[02:18:05] <wesley.m.eddy> touch on automatic iw
[02:19:21] <wesley.m.eddy> slide: overview
[02:19:38] <wesley.m.eddy> slide: proposed algorithm
[02:20:49] <wesley.m.eddy> lars at mic
[02:20:59] <wesley.m.eddy> haven't read, but wants to make sure he understands
[02:21:15] <wesley.m.eddy> clarification - picks an IW such that 95% do NOT have losses
[02:21:29] <wesley.m.eddy> slide: algorithm properties
[02:22:04] <wesley.m.eddy> slide: proposed constants
[02:23:24] <wesley.m.eddy> lars at mic: boxes run through entire port space in < MSL
[02:23:31] <wesley.m.eddy> joe: don't want to talk about numbers
[02:23:40] <wesley.m.eddy> tim: some boxes open connections that never run up against IW
[02:24:02] <wesley.m.eddy> shouldn't turn it up unless it's been tested
[02:24:19] <wesley.m.eddy> slide: issues
[02:25:48] <wesley.m.eddy> ilpo standing at mic
[02:26:02] <wesley.m.eddy> reordering
[02:26:29] <wesley.m.eddy> false positives - impact needs to be assessed
[02:26:41] <wesley.m.eddy> andrew: a lot of us have machines that go everywhere ... what about them?
[02:26:58] <wesley.m.eddy> speed of response on portable devices first connected to new network
[02:27:36] <wesley.m.eddy> could lose horribly if you tuned somewhere else and then arrive on the wrong kind of network later
[02:27:52] <wesley.m.eddy> lars: on andrew's point ... start from scratch when IP changes
[02:28:09] <wesley.m.eddy> joe: nobody's address is static for 10 years
[02:28:41] <wesley.m.eddy> mirja: general comment - don't know about iw at all
[02:28:55] <wesley.m.eddy> most of connections long-lived doesn't have big benefit
[02:30:49] <wesley.m.eddy> mirja: not one value valid for all connections
[02:31:02] <wesley.m.eddy> joe: for 30 yrs have had 1
[02:31:56] <wesley.m.eddy> igor (yahoo): thinks is great; disagrees with jerry - 10 not right number; 16 great for some, 7 for others, no universal number; should do something like this per subnet
[02:32:34] <wesley.m.eddy> tim: don't think he knows enough yet
[02:33:08] <wesley.m.eddy> something more adaptive is better than constant; on right track, but adaptive on shorter timescale is probably better
[02:34:07] <wesley.m.eddy> encourage to proceed, research, write drafts; make WG item later
[02:34:14] <wesley.m.eddy> joe: confusing expt with std track
[02:35:28] <wesley.m.eddy> jerry: kind of like it, but many devices don't stay up; persistent storage and complexity
[02:36:58] <wesley.m.eddy> lars: partly agree w/ tim
[02:37:18] <wesley.m.eddy> should adopt, but think more before adopting (?) don't adopt this document now
[02:37:37] <wesley.m.eddy> go up slow; down fast
[02:39:00] <wesley.m.eddy> lars: what's the rush
[02:39:17] <wesley.m.eddy> joe: every revision, arguments about algorithm & constants
[02:39:34] <wesley.m.eddy> what if we can't make it work ...
[02:39:40] <wesley.m.eddy> joe: that's why it's experiment!
[02:39:56] <wesley.m.eddy> lars wouldn't adopt now
[02:40:15] <wesley.m.eddy> matt: all answers are wrong; don't know what right one is
[02:40:31] <wesley.m.eddy> problem with class of solutions is the state variable sthat below elsewhere than end system
[02:40:37] <wesley.m.eddy> depends on class of end systems
[02:43:17] touch joins the room
[02:43:34] <wesley.m.eddy> mirja on accurate ecn feedback in tcp
[02:46:08] <wesley.m.eddy> slide: conex
[02:47:22] <wesley.m.eddy> slide: accurate ecn feedback in tcp
[02:48:22] <wesley.m.eddy> next slide
[02:52:11] <wesley.m.eddy> slide: simulation
[02:52:59] <wesley.m.eddy> slide w/ graph
[02:54:35] <wesley.m.eddy> slide on lmitations / conclusion
[02:55:33] <wesley.m.eddy> feedback?
[02:55:44] <wesley.m.eddy> lars at mic (richard broke it)
[02:56:05] <wesley.m.eddy> minor question - last he heard about nonce, was very quiet, is that still used somewhere?
[02:56:18] <wesley.m.eddy> nonce was exp, hasn't seen much use
[02:56:22] <wesley.m.eddy> can we reclaim it?
[02:57:28] <wesley.m.eddy> richard: input of ecn feedback is broader than for single evnet; in dctcp you need accurate feedback and it is important for basic security to avoid cheating
[02:57:31] <wesley.m.eddy> lars means current ecn nonce bit
[02:57:45] <wesley.m.eddy> do you want something new instead
[02:57:51] <wesley.m.eddy> matt - no implementations in field
[02:58:08] <wesley.m.eddy> compat with standard never launched not so important
[02:58:25] <wesley.m.eddy> ecn itself easy to turn on; nonce not all there
[02:58:50] <wesley.m.eddy> matt: such a tiny counter is in danger of missing a lot
[02:59:01] <wesley.m.eddy> deployment is more painful to use TCP options, but outcome is better
[02:59:38] <wesley.m.eddy> even a 3bit counter not big enough to work at scale
[02:59:59] <wesley.m.eddy> version with 3 counters too large/heavy
[03:00:20] <wesley.m.eddy> richard: commenting on matt, unused flag bits in header; coulde increase using those (joe putting head in hands)
[03:00:23] <wesley.m.eddy> mirja disagrees
[03:01:14] <wesley.m.eddy> 7ish interested
[03:03:59] <wesley.m.eddy> richard on transparent tcp timestamps
[03:04:17] <wesley.m.eddy> slide: agenda
[03:04:52] <wesley.m.eddy> slide: tcp timestamp echo on syn
[03:06:16] <wesley.m.eddy> slide: tcp timestamp echo on syn
[03:07:06] <wesley.m.eddy> next slide
[03:08:23] <wesley.m.eddy> next slide
[03:10:40] <wesley.m.eddy> joe: rfc says SHOULD; but this is a violation
[03:11:05] <wesley.m.eddy> 3023 says new connection, you have no knowledge
[03:11:21] <wesley.m.eddy> next slide
[03:11:48] <wesley.m.eddy> all have the same title apparently, this one begins with "as timestamp values ..."
[03:12:08] <wesley.m.eddy> joe: does that pollute the RTT calculation?
[03:14:45] <wesley.m.eddy> slide: tcp rto calculation
[03:15:47] tplunke\40jabber.org leaves the room
[03:15:48] <wesley.m.eddy> ladder diagram
[03:17:06] <wesley.m.eddy> slide: major changes since -01
[03:18:15] <wesley.m.eddy> yoshifumi: have you ever thought of using a new option instead of timestamp
[03:18:31] <wesley.m.eddy> completely interopperable with current deployments (tim agrees)
[03:18:55] <wesley.m.eddy> false negative/positive rates were low (negligible)
[03:19:31] <wesley.m.eddy> 10ish want to continue discussion
[03:19:56] <wesley.m.eddy> tim asks what the conclusion was
[03:20:09] <wesley.m.eddy> need more feedback; discuss on ML
[03:20:20] <wesley.m.eddy> per starting presentation
[03:20:33] <wesley.m.eddy> TCP and SCTP RTO Restart
[03:20:54] <wesley.m.eddy> slide: motivation
[03:22:23] <mscharf> Unfortunately, I have a significant audio lag
[03:22:43] <wesley.m.eddy> next motivation slide with ladder
[03:22:44] <wesley.m.eddy> slide: impact
[03:23:00] <mscharf> But according to what I have heard, it seems obvious that more discussion on the mailing list is needed for the timestamp draft
[03:23:03] <wesley.m.eddy> next impact slide
[03:23:27] <wesley.m.eddy> michael - yes, that was what yoshifumi declare
[03:24:28] <wesley.m.eddy> slide: costs v benefits
[03:25:33] <wesley.m.eddy> asking for feedback
[03:25:50] <wesley.m.eddy> richard: interactions w/ his draft; all for reducing RTO, but would like to investigate more
[03:26:09] <wesley.m.eddy> joe: bothers me that it makes TCP complicated when we don't know if it will matter
[03:26:41] <wesley.m.eddy> per: depends on settings
[03:26:51] <wesley.m.eddy> joe: does the amount really matter
[03:26:56] <wesley.m.eddy> matt: it matters to us (google)
[03:27:17] <wesley.m.eddy> joe: heard the rant before; when google's gone, will we have to clean this up
[03:27:23] <wesley.m.eddy> matt: we care; talk offline
[03:27:34] <wesley.m.eddy> mirja: do we need an ietf doc?
[03:27:55] <wesley.m.eddy> per: would be nice to have something written; matt seconds that
[03:28:04] <wesley.m.eddy> yoshifumi: not tcp-specific
[03:28:15] <wesley.m.eddy> question is whether we do it in tsvwg
[03:28:52] <mscharf> if it affects TCP's RTO, I think that it is in scope of TCPM
[03:29:11] <wesley.m.eddy> joe - needs to be coordination between wgs
[03:29:18] <wesley.m.eddy> would google care for sctp?
[03:29:25] <wesley.m.eddy> more here than there
[03:29:46] <wesley.m.eddy> around 6ish interested; continue on ML
[03:29:51] touch leaves the room
[03:30:17] wesley.m.eddy leaves the room
[03:30:49] <mscharf> Thanks to Yoshifumi and Matt for helping the chairs!
[03:34:29] mscharf leaves the room
[03:37:03] zcao leaves the room
[03:41:25] mattmathis leaves the room
[04:50:57] touch joins the room
[04:59:53] touch leaves the room
[05:27:56] wesley.m.eddy joins the room
[05:28:19] wesley.m.eddy leaves the room
[05:39:03] mattmathis joins the room
[05:59:56] mattmathis leaves the room
[07:15:54] tplunke\40jabber.org joins the room
[07:16:01] tplunke\40jabber.org leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!