Tuesday, 26 July 2011< ^ >
jishac has set the subject to: TCP Maintenance and Minor Extensions WG
Room Configuration

[12:42:01] gorryf joins the room
[12:43:11] <gorryf> tcpm at IETF81,
[12:43:47] <gorryf> Audio stream <> - please report problems via this jabber session
[12:45:55] rscheff joins the room
[12:58:10] Christoph Paasch joins the room
[12:59:08] <rscheff> Good morning!
[13:00:08] <Christoph Paasch> Good afternoon... ;)
[13:00:27] <rscheff> are the slides uploaded already?
[13:00:57] <rscheff> affirmative
[13:01:19] <gorryf> Did you hear the opening words on teh audio ...?
[13:01:26] <Christoph Paasch> yes
[13:01:34] <gorryf> Thanks
[13:05:42] fgont joins the room
[13:06:45] <gorryf> WG admin & status
[13:08:40] dborman joins the room
[13:09:16] <gorryf> Note taker: Andrew Lachlan
[13:10:02] <gorryf> Slide: Active work items
[13:12:02] <gorryf> Slide: Under Poll to Become a WG ITem
[13:13:22] <gorryf> Slide: Chair's report on IW increase
[13:14:25] <gorryf> Slide; There are many choices...
[13:16:58] <gorryf> Slide: Some further aspects
[13:17:32] Lars joins the room
[13:19:24] <gorryf> 3 questions for discussion in this meeting:
[13:19:25] <gorryf> Slide: 1) Track for draft-ietf-tcpm-initcwnd
[13:22:34] <rscheff> mike?
[13:23:09] <gorryf> Slide: 2) What maximum value?
[13:24:28] Lars leaves the room
[13:24:28] <gorryf> Mirja:
[13:24:37] <gorryf> Did you ever try to pace the 10 over one RTT?
[13:24:38] <rscheff> microphone?
[13:25:19] <gorryf> Answer: No. Packet pacing is a way to mitigate the burst. This adds complexity and we don't think this is needed if you do not go beyond 10.
[13:25:39] <gorryf> If you go beyond 10, this will be an issue.
[13:25:53] <gorryf> Slide: 3) Adaptive scheme as alternative
[13:26:52] Lars joins the room
[13:27:09] Lars leaves the room
[13:27:22] <gorryf> Colin Perkins at Mic
[13:27:50] <gorryf> Colin: My concern is the impact these have implications on non-TCP traffic.
[13:28:35] <gorryf> Colin: The measurements I saw seemed to have on other TCP traffic. I haven't seen analysis on the impact of VoIP traffic.
[13:29:00] <gorryf> Matt: TCP is designed to create queues. This is a design feature.
[13:29:15] <gorryf> Colin: This does not help VoIP.
[13:29:38] nestor.tiglao joins the room
[13:29:50] <gorryf> Matt: This is a drop in the bucket compared to other issues.
[13:30:18] <gorryf> Ans: We did not see significant issues on VoIP.
[13:30:26] <gorryf> Colin: Not sure I udnerstand.
[13:31:17] nestor.tiglao leaves the room
[13:31:32] <gorryf> Jana: I have concern on static values. Jim Gettys is looking at buffer bloat, this needs to be fixed - a fixed value IW=10 and this will cause an issue.
[13:32:01] nestor.tiglao joins the room
[13:32:22] <rscheff> I think Jim likes to remove deep buffers accounting to many 1000s of packets - not 10s of packets...
[13:32:28] <gorryf> Lars Eggert: I do not think option A (fixed value in PS) is not typical of TCPM and seems too bold. Option B seems the best, I like option B best to allow the experience of deployment.
[13:32:55] <gorryf> Lars: I'm not sure I expect to see a dynamic increase deployed.
[13:33:38] <gorryf> Lars: The potential for harm is not high, it seems there is not much threat if there are not many flows.
[13:34:03] <gorryf> Lars: It would be interesting to see a long-term adaptive scheme experiment.
[13:34:39] <gorryf> Cathy Nichols: I would go for option A - you should choose 10, and you can revise this later,
[13:35:08] <gorryf> ..: Buffer bloat is a diffrerent problem - use DS and a seprate queue.
[13:35:51] <gorryf> Scott Bradner: Lots of flows... Jim is worried by the number of flows opened in a modern browser - this means many flows do cause queues.
[13:36:11] <gorryf> ?: Serialisation delay is a major issue on VoIP traffic.
[13:37:22] Lars joins the room
[13:37:24] <gorryf> Colin: My concern is that I do not want to have a discussion in a few years on how buffer bloat will occur as a result of IW=10.
[13:37:27] wesley.m.eddy joins the room
[13:37:52] <gorryf> Jana: There seems to be no difference between a or b - standards status does not matter regarding implementation.
[13:39:10] <gorryf> Jana: If it goes to experimenal, let's define what is needed to make it PS
[13:39:26] <gorryf> Andrew McGreggor: how big was the queue?
[13:39:44] <gorryf> Ans: 1000, it was the default for Linux
[13:40:19] <gorryf> What is the meaning of the experimental status? What does experimental mean for OS vendors?
[13:40:32] <gorryf> Can they turn-on by default?
[13:40:46] <rscheff> commercial vendors will probably not implement experimental
[13:41:09] <gorryf> Michael: For F-RTO fixed issues in experimental status.
[13:42:00] <Lars> all of them implemented f-rto when it was experimental
[13:42:37] <gorryf> Colin: The IETF can not control what implentors implement. We need to say what the concerns ARE and ask vendors to evaluate them - provide guidance.
[13:43:33] <gorryf> : This is one reason I favour standard,... within google it was experimental for 3 years!
[13:44:37] <gorryf> Andrew: For example, Linux implementors make a judgment call and decide what to do. Linux have deployed 10.
[13:45:20] <gorryf> Andrew: Someone needs to do the checking to see if this raises issues. Someone needs to do the work.
[13:45:44] <gorryf> : Google is happy that the results of 2 years have been analysed.
[13:46:03] <gorryf> : IW=10 is an upper bound. It does not require IW=-10.
[13:47:16] <gorryf> Matt: I observe all of these answers are wrong. in 10 years IW=10 will be too small. the right answer is an adaptive algorithm and the values are determined by IANA via the IETF.
[13:48:03] <gorryf> Matt: How many people were involved in the IETF before it was a standard.
[13:48:54] <gorryf> Matt: I don't believe transport really is standardised, the real standards are in the stack.
[13:49:48] <gorryf> Lars: Standards Track says to the world that we believe as the IETF that this is ready for global deployment. I do not think we are yet there for this. I think this is on the path.
[13:50:33] <gorryf> ..on the path towards being a standard very soon. Experimental may mean you can deploy this and there are things to watch that we will revisit this in the future.
[13:52:23] <gorryf> Jana: If we go to EXP with IW=10, is it possible to know if TCP is hurting other flows? Can we then get stacks to reduce this?
[13:53:07] <gorryf> : We have done studies that show IW=10 does not impact other traffic.
[13:54:36] <gorryf> Andrew McGreggor: I think there should be a registry I agree, This difference benefits web servers, and Linux us widely used for this.
[13:55:35] <gorryf> Randal: EXP for ECN did not cause an issue, and that was good. I think EXP would let us experiment - at least via a sysctrl, and do the experiment for 2 years.
[13:55:51] <gorryf> Matt: Do you think it will go faster as PS or EXP.
[13:56:13] <gorryf> Randall: I think this makes NO difference, people will implement.
[13:56:45] Christoph Paasch leaves the room
[13:56:45] Christoph Paasch joins the room
[13:56:45] Christoph Paasch leaves the room
[13:56:53] <gorryf> Nandita: What are we looking for to make this a PS?
[13:56:56] Christoph Paasch joins the room
[13:57:11] <gorryf> Lars: Should we require ECN if you sue IW>3 ???
[13:57:20] <rscheff> +1
[13:57:47] <gorryf> Lars: I think google has done the homework for their types of traffic - and this is really good, I wish others would do this.,
[13:59:06] <gorryf> Lars: Let's say what the experment is? - we should have mechansims to monitor whether the user experience is good, and some statement like this is needed.
[13:59:18] Christoph Paasch leaves the room
[14:00:15] <gorryf> Jana; If we knew the issues this would be fixed in the draft. The Internet may reveal new issues, and we need to know how to measure the impact.
[14:00:41] <gorryf> Mirja: I would like to see more experience of other uses on the Internet.
[14:01:24] <gorryf> Colin: I think Lars made a good statement. Turn it on and how it impacts TCP and your other applications.
[14:02:44] <gorryf> Matt: Challenge is finding collatoral damage. This impacts the download completion time.
[14:04:01] <gorryf> Matt: Content providers are usurping the ability of web servers. There are many uses that structure data to try to overcome this.
[14:04:15] <gorryf> Matt: TCP does this
[14:05:19] <gorryf> Nandita: We measure our own packet latency and we don't find degradation for equivalent traces.
[14:06:54] <gorryf> Lars: There has been a good body of work on this by google from their perpective. Other users should also monitor there succes in different use-cases..
[14:07:10] <gorryf> Mirja: We should allow a socket option to let the app choose.
[14:07:22] <gorryf> Call for adoption as PS?
[14:07:26] <gorryf> - 3 people
[14:07:42] <rscheff> +1
[14:07:44] <rscheff> exp
[14:08:22] <gorryf> Those who think it should go EXP?
[14:08:25] <gorryf> 20+1
[14:08:39] <gorryf> Those who think neither should happen?
[14:08:41] <gorryf> Neither
[14:09:14] <gorryf> Conclusion - we have a measure of the room
[14:09:44] <gorryf> Mirja: Can we ask if people do not know also?
[14:10:05] <rscheff> A: go withIW10
[14:10:05] <gorryf> Asking now for people who think 10 is reasonable?
[14:10:16] <gorryf> - About 10
[14:10:19] <rscheff> Draft should talk about other MSS too
[14:10:36] <gorryf> Need discussion?
[14:10:38] <gorryf> 1
[14:11:18] <gorryf> Would it be benefical to have a long term evolution?
[14:13:13] <gorryf> Andrew: I don't know this is anywhere nearly adaptive enough for cell phones and laptops
[14:13:38] <rscheff> +1
[14:13:56] <rscheff> in principle +1
[14:14:30] <gorryf> Gorry - as individual: I agree with Andrew. I also worry whether we have the right measure to judge when it goes wrong, we may need to be more conservative if things go wrong.
[14:14:56] <rscheff> like Matts suggestion!
[14:15:20] <rscheff> mic?
[14:15:34] <gorryf> Michael Tuxeon: let's look at this for all transports not just TCP.
[14:15:59] <gorryf> Colin: Can we look at adaptability as a separate question?
[14:16:09] <rscheff> +1
[14:16:13] <gorryf> WG Calls this - should we do work in this space:
[14:16:19] <gorryf> 8+2
[14:16:26] <gorryf> Against: None
[14:16:40] <gorryf> Those who support this as a specific work item at this time?
[14:16:44] <gorryf> 1.5 for
[14:16:55] <gorryf> Some other draft/proposal ?
[14:16:59] <gorryf> 6 or so.
[14:17:26] <gorryf> Lars abstained because he wanted to see implementor backing to the approach.
[14:17:50] <gorryf> Who would like to work with Joe or provide feedback/alternatives?
[14:17:53] <gorryf> approx 3
[14:19:07] <gorryf> Consensus: The room seems to think that EXP is the best approach, IW=10 is a good proposal, we do not yet know if the automatic adjustment is acceptable (there needs to be more discussion). This will be taken to the list.
[14:19:12] <gorryf> ----------------------------------------
[14:19:27] <gorryf> Matt next on Proportional rate reduction
[14:20:08] <gorryf> Slide: Motivation
[14:22:02] <gorryf> Slide: Prop. rate reduction with slowstart reduction bound
[14:23:28] <gorryf> Next slide:
[14:24:40] <gorryf> Next Slide: (sorry the font isn't good for reading this one). Skip next slide.
[14:25:45] <gorryf> Slide: Measurement setup
[14:26:26] <gorryf> Slide: measurement summary (it works)
[14:27:15] <gorryf> Rate halving did not work as well as the new method.
[14:27:24] <gorryf> Slide: Conclusion.
[14:27:31] <gorryf> Slide: Going Forward.
[14:28:10] <gorryf> Chairs: Are results availabnle - the camera ready version will be published on the web site.
[14:28:44] <gorryf> Randall: I remember a long time ago, that SUN implemented maxbursts, SCTP implemented this and did not see this.
[14:29:04] <gorryf> Matt: The way that maxburst was implemented this changed cwnd...
[14:29:15] <gorryf> Randall: Both approaches were commented.
[14:29:24] <gorryf> Matt: 10 years I got stuck on this.
[14:29:36] <gorryf> ... it was exactly that question.
[14:30:06] <gorryf> Michael: The difference is whether the app generates mircibursts and what the differences may be.
[14:31:13] <gorryf> Gorry: Would this make the draft unuseful? or is it a potential issue for this draft?
[14:31:44] <gorryf> Matt: The extra complexity of doing this as well was something we wished to avoid. We did talk with the chairs about this.
[14:31:54] <gorryf> Andrew: This all seems a good thing.
[14:32:21] <gorryf> Jana: There has been other work on microbursts.
[14:32:39] <gorryf> Nandita: These are not on topic.
[14:32:40] <rscheff> +1
[14:32:47] <gorryf> Who has read this?
[14:32:56] <gorryf> 5-6 + 1 (jabber)
[14:33:06] <rscheff> +1
[14:33:10] <gorryf> Who should adopt this as a work item?
[14:33:14] <gorryf> 8+1
[14:33:20] <gorryf> Who would not adopt?
[14:33:22] <gorryf> None
[14:33:59] <gorryf> The consensus is that there is some support for adoption, and we will post this to the mailing list to confirm this,
[14:34:06] <gorryf> ---------------------------------------------------
[14:34:15] <gorryf> jerry Chu - data in syn
[14:34:25] <gorryf> Slide: Quick Recap
[14:36:29] <gorryf> Slide: Key Issues
[14:42:08] <gorryf> Slide: Amplified Reflection
[14:43:11] <gorryf> Slide:can cookie be optional?
[14:43:59] <gorryf> Slide: sending data in syn-recv state
[14:46:53] <gorryf> Slide: client data
[14:47:33] <gorryf> Slide: New state transitions
[14:50:34] <gorryf> Slide: API
[14:51:41] Lars leaves the room
[14:52:46] <gorryf> Mirja: Are you asuming every client requests a cookie without knowing the server supporting this?
[14:53:15] <gorryf> Chu: Will try to negotiate by default.
[14:53:24] <gorryf> Mirja: For every connection?
[14:53:33] <gorryf> Chu: It may be an option
[14:53:35] <gorryf> Slide: Handshake Overhead
[14:54:55] <gorryf> Slide: +1
[14:55:48] <gorryf> Slide: Whole page
[14:58:33] <gorryf> Randall at Mic: In the example how big is the page? Is this IW=10?
[14:58:40] <gorryf> : Yes IW=10
[15:00:32] <gorryf> Gorry: Is the data set from a mobile case?
[15:00:48] <gorryf> : Not actual mobile dya,
[15:01:48] <gorryf> Gorry: So the biggest benefit was for mobile, but I expect caching an RTT estimate and re-using this in a mobile case to seed RTO is actually quite problematic - in this case the RTT for a new SYN could be quite different. Did you look at this>
[15:02:23] <gorryf> Chu: We agree, this data does not look at this. we would like to keep RTO low, 3 secs for RTO is not a good option.
[15:02:31] <gorryf> Slide: related proposal
[15:05:22] <gorryf> Slide: contd
[15:07:06] <gorryf> Slide: Impl. Status
[15:07:19] <gorryf> Next: Questions?
[15:08:37] <gorryf> Wes Eddy: TCP CTRR has been submitted to the independent stream for consideration . It is being reviewed right now.
[15:09:01] <rscheff> the mic in the back is not working properly...
[15:09:18] <gorryf> Lars: The document was by Bill Simpson. - It is using the exp optional number.
[15:09:31] <gorryf> Lars: do not conflict with that option number.
[15:09:48] nestor.tiglao leaves the room
[15:09:54] <gorryf> Is the Mic used by Lars working?
[15:10:05] <rscheff> was lars speaking?
[15:10:17] <rscheff> (no )
[15:10:51] <gorryf> The other draft will not have an option number assigned - because it does not come from the IETF review
[15:11:08] <gorryf> Wes: I need to know if this conflicts with existing IETF work.
[15:11:48] <gorryf> Chu: It needs to be PS. Does this need to be a PS?
[15:11:57] <rscheff> now i hear lars
[15:12:25] <gorryf> Lars: This needs to be PS or it needs to be IESG approved. The WG could ask for this for an EXP from a WG.
[15:12:42] <gorryf> Authors would like to see WG adoption.
[15:14:07] <gorryf> Chair: The christmas tree effect may cause problem with IDS?
[15:14:19] <gorryf> Chu: We do not send SYN+FIN.
[15:14:35] <gorryf> Chair: how many packets get dropped in real networks?
[15:14:53] <gorryf> Chu: less than 10% midboxes have issues.
[15:15:46] <gorryf> - : I have similar data. I found one box reset data in 500,
[15:16:03] <gorryf> - This results in a RST.
[15:16:31] <gorryf> Chair: how does this interact with IW=10?
[15:16:56] <gorryf> Chu: Not looked at this yet.
[15:17:12] nestor.tiglao joins the room
[15:17:28] <gorryf> Chair: The 3-way path gives some protection for paths.
[15:18:06] <gorryf> Chu: There is more work to do, if we take this forward.
[15:20:15] <gorryf> Chair: How does this react with mechanisms that use the SYN to probe for IPv6 versus IPv4
[15:20:44] <gorryf> Chu: Similar to the case for RTO=1 sec
[15:20:59] <gorryf> Gorry - note on RTT caching to reduce this value.
[15:21:19] <gorryf> How many have read this?
[15:21:26] <gorryf> How many support this?
[15:21:33] <gorryf> How many would also help?
[15:21:37] <gorryf> ans: 4-5.
[15:22:06] <gorryf> Consensus: Is we will take this to the list - we note the interest.
[15:22:15] <gorryf> Andrew McGreggor was the TCPM notetaker.
[15:22:18] wesley.m.eddy leaves the room
[15:22:33] <rscheff> thx
[15:22:35] rscheff leaves the room
[15:27:48] nestor.tiglao leaves the room
[15:28:12] gorryf leaves the room
[15:55:18] fgont leaves the room
[15:57:39] nestor.tiglao joins the room
[16:04:48] nestor.tiglao leaves the room
[16:09:55] nestor.tiglao joins the room
[16:26:48] dborman leaves the room
[16:47:49] nestor.tiglao leaves the room
[16:47:53] nestor.tiglao joins the room
[16:59:40] wesley.m.eddy joins the room
[16:59:50] wesley.m.eddy leaves the room
[17:00:19] wesley.m.eddy joins the room
[17:04:12] nestor.tiglao leaves the room
[17:53:52] wesley.m.eddy leaves the room
[20:17:32] fgont joins the room
[20:28:50] fgont leaves the room
[22:04:34] fgont joins the room
[22:24:10] fgont leaves the room