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

GMT+0
[13:41:32] Michael Scharf joins the room
[13:46:52] PasiS joins the room
[13:50:46] Alexander Zimmermann joins the room
[13:57:12] jlcJohn joins the room
[13:57:34] Wes George joins the room
[13:57:55] <Wes George> anyone have the audio stream working yet?
[13:58:18] <Alexander Zimmermann> could anyone give me the audio link?
[13:58:32] <Wes George> http://ietf85streaming.dnsalias.net/ietf/ietf855.m3u
[13:58:35] <Wes George> I got an error
[13:59:06] <Michael Scharf> No audio for me neither
[13:59:07] gorryf joins the room
[13:59:23] wesley.m.eddy joins the room
[13:59:28] <Alexander Zimmermann> m2
[13:59:33] <gorryf> Hi I'm in the "real" TCPM meeting room in rainy Atlanta
[13:59:41] <jlcJohn> no audio here either...
[13:59:41] <gorryf> Can remote people here Pasi?
[13:59:42] <Wes George> the stream server appears to be down
[13:59:51] <Wes George> I couldn't get on another audio stream (IDR) either
[14:00:02] <Wes George> someone should probably alert the secretariat
[14:00:02] <PasiS> ouch
[14:00:44] <PasiS> wes is sending emaiö
[14:00:48] <PasiS> *email*
[14:00:56] <Alexander Zimmermann> it works now
[14:01:04] <PasiS> great
[14:01:06] <Michael Scharf> yes, it works
[14:01:41] Andrew McGregor joins the room
[14:02:18] <gorryf> Agenda - any comments?
[14:03:10] <gorryf> WG Items with Chairs
[14:03:20] <gorryf> 2 Active work items to discuss today
[14:03:30] <Wes George> the audio is very quiet at max volume
[14:05:16] <gorryf> RFC 2313bis Next
[14:05:51] Zahed joins the room
[14:07:46] <Zahed> which presentation?
[14:08:05] <gorryf> RFC 1223bis status - questions now?
[14:08:24] <gorryf> Pasi: Who has read the draft?
[14:08:26] <gorryf> (4)
[14:08:28] <Alexander Zimmermann> only diffs
[14:08:44] <jlcJohn> make that 5
[14:08:46] <Zahed> thanks
[14:08:58] <gorryf> Is it worthwhile to update the introductory material?
[14:09:11] <gorryf> Mattt: The document has a lot of historical features
[14:09:28] <gorryf> Mat: teh docuemnt does not say when you use PAWS you must set DF
[14:09:38] <jlcJohn> good catch, Matt!
[14:09:47] <gorryf> Mirja: If no-one has read this completely, please shorten this a little
[14:10:22] <gorryf> Matt: half of the text is about things that were done a while ago - perhaps omit this and refer back to RFC 1323?
[14:10:24] <Alexander Zimmermann> i agree with matt / mirja
[14:10:56] <gorryf> NEXT: TCP Fast Open
[14:11:32] <gorryf> Clarification of SYN-data issue (replay)
[14:11:32] <Alexander Zimmermann> what is about the late timestamp negotiation?
[14:12:16] <Alexander Zimmermann> imo the change that richard has made is too implicit
[14:12:25] <Michael Scharf> I think I asked the same question in the last meeting... Not much feedback
[14:12:37] <wesley.m.eddy> looks like guys are here to work on the audio steram
[14:12:59] <Michael Scharf> For me, audio is fine
[14:13:33] <Alexander Zimmermann> maybe a section with some discussion about it would be good
[14:13:36] <jlcJohn> audio OK here, but handling mike hurts my ears...
[14:13:55] rscheff joins the room
[14:14:16] <gorryf> Bob at Mic:
[14:14:27] <Wes George> it's a little on the quiet side for me, and I'm using headphones at max vol. I can understand everything though
[14:15:30] <gorryf> TS echoed in the cookie ... but the cookie can be used twice
[14:15:40] <rscheff> i don't know if we want to make a larger change wrt late TS negotiation than the removal of the half-sentence (and thus allowing the factual behavior of a lot of stacks)
[14:16:44] <Alexander Zimmermann> BTW: I'm a volunteer for reviewing 1323bis
[14:17:49] <Michael Scharf> @Alex: Thanks!
[14:18:40] <rscheff> @alex thx
[14:19:47] <Alexander Zimmermann> BTW 2: the TCP roadmap-bis is not dead - the winter is coming - hoping for more time
[14:22:34] <gorryf> bob : i think idempotency requires a subtle decision about when this works and when not.
[14:22:43] <gorryf> There are more issues
[14:22:50] Zhiwei Yan joins the room
[14:23:26] <Alexander Zimmermann> @Richard: With the deletion of the half-sentence, you allow the late negotiation, right? Do we have some experience what's happen if a stack negotiates the TS late?
[14:23:40] <Zhiwei Yan> No voice?
[14:24:02] <Alexander Zimmermann> Voice works
[14:24:17] <Alexander Zimmermann> Bob is very clear :-)
[14:25:58] <Michael Scharf> Regarding data in SYNs: Is there an issue with crossing SYNs? (just wondering...)
[14:27:59] <PasiS> want that to be asked on mic?
[14:28:04] Zhiwei Yan leaves the room
[14:28:24] <Michael Scharf> Yesm I'd be curious if it is an issue. I just don't know
[14:28:41] <PasiS> crossing SYNs?
[14:28:49] <PasiS> can you open up that
[14:29:27] <Michael Scharf> what happens if both enpoints try to open a connection, both with data in SYNs... It is really a corner case.
[14:29:38] <PasiS> ah right
[14:31:07] <Michael Scharf> (this part of the TCP state engine might be historic...)
[14:31:46] nestor.tiglao joins the room
[14:31:59] <jlcJohn> Michael: it's not "historic" to the extent that it never happens, least of all prevented by implementations
[14:34:47] <gorryf> GF Notes on what I said: 1) An applicability statement would be really useful for people who do not care at all about TCP but just want to send bytes - a separate section would be good to just say when to use this,
[14:35:32] <gorryf> GF 2: It would be really nice to see SHOULD cache the bad state to avoid persistent use of this over paths that can't support this.
[14:36:43] <gorryf> GF3: It would be nice to see the argument on the list about why this change of protocol behaviour is not more aggressive
[14:36:54] <gorryf> Jana: we do need to look at simul open case.
[14:37:06] <gorryf> Bob: <I missed these see notes>
[14:37:34] <gorryf> NEXT: Mirja, more accurate ECN
[14:37:41] michael.welzl joins the room
[14:38:11] <rscheff> @alex: when I investigated a whole bunch of different stacks (linux, solaris, aix, bsd, windows). when my test client set up a session, and started sending TS with the 1st or 2nd data packet, none of the sessions terminated; some stacks (most notably linux in the versions i checked) started returning TS, just as one would expect with the new wording...
[14:40:20] <gorryf> Bob: There is another issue that DCTCP has a "flakey" feedback mechanism. There are a range of proposals. There is an interop issue.
[14:40:51] <gorryf> Bob: Conex and DCTCP are two implementations that do not interop.
[14:44:41] <gorryf> Mirja Slide 4: Design Approaches
[14:45:04] <gorryf> Is there interest?
[14:45:27] <gorryf> - Is there a possible way to collect bits over a period and then respond to these?
[14:45:47] <gorryf> Mirja: This could be a design approach
[14:46:17] <gorryf> - Receiver could have more intelligence in how to return the data
[14:46:40] <gorryf> -; There could be a certain window and respond.
[14:47:05] <gorryf> Mirja: this resembles dctcp, but conex would value this more if the info was available right away.
[14:47:23] <gorryf> -: If the router does ARM/CoDel etc then it is a random mark
[14:48:40] <gorryf> Andrew McGregor: If you mark every packet - you track the density, you are not delayed by a RTT.
[14:49:03] <gorryf> Bob: There is more delay than just sending the value asap.
[14:49:20] <Alexander Zimmermann> @Richard: cool. Is it not worthwhile to include this test (the output) into the doc?
[14:49:44] <gorryf> Bob: Mirja is talking about how to return the info and it is not specifically about how to do the CC that uses this.
[14:50:49] <gorryf> -: What sort of bandwidth do we need ... we need 5 or 6 bits per packet to signal a counter value as described on the previous slide (we only have 3 bits).
[14:51:17] <gorryf> jana: It's easy to send accurate ECN - what is not clear whether you will receive it at the sender
[14:51:56] <gorryf> Mirja: There may be no proposal that satisfies all issues.
[14:52:47] <gorryf> Jana: SACK gives more accurate feedback - but SACK has no reliability requirement, because we know what the sender will do with the information. This is important in the design.
[14:53:06] <gorryf> Bob: We try to make the info reliable by repetitin
[14:53:32] <gorryf> Jana: We should be careful about what reliability we need
[14:54:00] <gorryf> Mirja: we need to provide flexibility for future use cases. At the moment we don't have info, so we can not think about these use cases.
[14:55:12] <gorryf> Bob: The current scheme only repeats, assuming you don't loose a whole RTT of ACKs
[14:55:33] <gorryf> Mirja: This is also a signal (Randall: It's called a RTO)
[14:56:14] <gorryf> -: The signal can be coded over 1 RTT, but could also be relaxed timing where some of the info is spread over multiple RTTs.
[14:56:41] <gorryf> Mirja; we need to judge whether complexity is worth this.
[14:57:48] <gorryf> Matt: We need guidance on how much information we need. e.g. what happens if we use this with lots of marks (e.g. DC) - then this would change the operation - we can not choose the signal transport until we know how it will operate.
[14:58:00] <gorryf> Mirja: Are there 2 cases?
[14:58:39] <gorryf> Matt: We may like to look at what is best in an Internet context, should we do more marks in this case also. All solutions will be approximations
[14:59:11] <gorryf> Bob: we need to do something to let us do research
[14:59:30] <gorryf> - : If we look for jitter, the TS can help this.
[15:00:02] <gorryf> - : Can we order the bits in order of "danger" - for use in the Internet.
[15:00:19] Ryan Hamilton joins the room
[15:00:40] <jlcJohn> mic: for research, the TCP option seems best at first blush. What would we need to do to assign a TCP option for that research?
[15:01:05] <gorryf> - : Can we use the urgent bits when the pointer is not in use?
[15:01:21] <gorryf> - How much of a risk is there from middleboxes?
[15:02:31] Ryan Hamilton leaves the room
[15:02:49] <gorryf> Jana: Comment on Brian's comment - thsi seems in order of danger?
[15:04:20] Ryan Hamilton joins the room
[15:04:25] <gorryf> Jana: How can we use this?
[15:08:57] Wes George leaves the room
[15:09:13] <gorryf> Gorry: Can we just decide if the Urgent Bit can be re-used on a best effort basis.
[15:09:24] Wes George joins the room
[15:09:39] <gorryf> Pasi: as Chair, who is interested in working on this subject?
[15:09:45] <gorryf> <many>
[15:10:19] <gorryf> Pasi : We are not ready to work on document details, but it seems we are ready to work now on the problem statement
[15:10:32] <gorryf> Michael: TCP AND SCTP RESTART
[15:14:19] <gorryf> Mirja: Why are you restarting the timer, rather than keeping the old timer.
[15:14:44] <gorryf> Michael Tuz: The old timer could be very old - it is done as if the timer was for each message.
[15:16:44] <gorryf> Can we compare with TLP....This is looking at thin streams. It uses RTO. TLP more focussed on probes.
[15:17:23] <gorryf> Michael Tux: Why do you focus on thin streams? (can't you do all the time?)
[15:17:33] <gorryf> Yes, we can do this all the time.
[15:18:39] <gorryf> Michael Tux: It should be OK for SCTP to do this.
[15:19:02] <gorryf> It may not be worth the risk of a spurious RTO when there are more than 4 segs in flight.
[15:20:02] <gorryf> Jana: This is within the intended use of the TCP RTO.
[15:20:28] <gorryf> jana: How much gain is there?
[15:20:54] <gorryf> significant in certain cases. e.g. on-line game showing in previous talk
[15:21:25] <gorryf> Micahel Tux: This could be of interest in webrtc.
[15:24:07] Zahed leaves the room
[15:24:27] <gorryf> NEXT: TLP Talk
[15:33:53] <Alexander Zimmermann> question: could we compile an RFC (suppose TLP becomes an RFC) that depends on a algo. which is not standardized (FACK)?
[15:34:29] <Michael Scharf> This question was already raised on the list...
[15:34:55] <Alexander Zimmermann> ok - sorry
[15:34:59] <Michael Scharf> (Very valid, tough)
[15:35:38] <Alexander Zimmermann> i'm little bit behind with reading emails :-(
[15:35:42] <rscheff> FACK would need to be written down in a draft...
[15:36:07] <rscheff> (and it should, IMHO. Many (most?) stacks do fack i think...
[15:36:13] <michael.welzl> +1 on that a FACK document would be nice to have
[15:37:23] <Alexander Zimmermann> and maybe this is also a good time to write my reordering algo down into a draft...
[15:37:34] <Alexander Zimmermann> since FACK is not reordering robust
[15:39:52] <gorryf> Jana: This seems an important problem. I don't know if TLP is the right solution.
[15:40:12] <Wes George> side note for the chairs, aren't we supposed to be avoiding company-branded powerpoint templates?
[15:40:15] <gorryf> Repairing taildrops is improtant (70% of losses)
[15:41:06] <PasiS> i don't know, is there a specific rule about that?
[15:41:12] <gorryf> Stuart Chesire: We should avoid application developers feom avoid sending data in chunks with stalls between.
[15:42:13] <gorryf> - : It may not be bad application design, there can be synchronous applications that do send in chunks such as database apps.
[15:42:54] <gorryf> Stuart Cheshire; with a redirect, you don't have anything else to send; with a video stream - there is more data.
[15:43:06] <Wes George> I think it's a general recommendation, similar to how we don't ask people to state afiliation at the mic. I'll look to see if it's in the WG chair's faq
[15:43:28] <gorryf> - : There are perfectly valid use cases that need this.
[15:43:57] <gorryf> Stuart Cheshire: This applies when the receiver is stuck waiting for the data.
[15:44:29] <gorryf> Randal S; SCTP could (easily) use this method.
[15:44:57] <gorryf> Jana: DSACK does not let you know about >1 duplicate.
[15:45:50] <gorryf> TLP relies on FACK - which is not documented. FACK interprets SACK with a large gap in the scoreboard, then you trigger a fast recovery (rather than wait for multiple SACKs).
[15:46:29] <gorryf> Matt: If there is a big enough hole in the SACK block, send immediately. 3517bis includes the algorithm in one para.
[15:46:52] <gorryf> Marko: This is not quite the same as FACK - we need to check this.
[15:46:55] <Alexander Zimmermann> The new SACK is RFC 6675 <http://tools.ietf.org/html/rfc6675>
[15:47:45] <gorryf> Pasi: we have two proposals in this space.
[15:48:06] <gorryf> As WG Chair: Should we work on both approaches or are they overlapping?
[15:48:34] <gorryf> Goals are the same, but mechanisms are different. We always need an RTO.
[15:49:28] <gorryf> Michael Tux: The RTO document defines how to implement the RTO timer. That is a nice document to write, it's simple and should be in a separate document.
[15:50:43] <Alexander Zimmermann> and RFC6675 != FACK (but is closer to it as RFC 3517 was)
[15:52:56] <gorryf> Two documents should be separate.
[15:53:52] <gorryf> Jana: Don't characterise the issue as being thin-stream (this was a motivation, it's not the real issue)
[15:53:53] nestor.tiglao leaves the room
[15:54:07] nestor.tiglao joins the room
[15:55:45] <gorryf> Jana: I think WG adoption of the draft is too early - we may not be ready for the solution.
[15:56:11] <gorryf> Michael: I'd like to see SCTP handled the same way.
[15:56:28] <gorryf> Pasi: I think the document needs to be revised.
[15:58:47] <gorryf> People seem to support the activity, the document should be updated and discussed there.
[15:59:08] <gorryf> Mirja: please identify the problem more clearly
[15:59:51] <gorryf> Pasi: How many people would be interested in working on this document
[15:59:55] <gorryf> Many
[16:00:11] <gorryf> Humm to support adopting this as a working document
[16:00:14] <gorryf> <Hum>
[16:00:21] <gorryf> Against adoption?
[16:00:28] <gorryf> <None heard>
[16:03:26] <gorryf> Gorry: Do we know what the experiment is to check? - We should check with ADs to figure out the status of the draft.
[16:03:53] <gorryf> Micahel W: The test is how often is the spurious RTO?
[16:04:36] <Michael Scharf> Yes, I agree that the spurious RTO risk is the experiment. Particular in wireless
[16:04:42] <gorryf> Andrew McG: I think there is a good chance to do the experiment before publication.
[16:05:01] <gorryf> Jana: I'd like to see more experiments
[16:07:42] <Wes George> can smoeone else jabber scribe while gorry is presenting?
[16:07:52] <Wes George> which slides are we looking at, etc?
[16:08:25] <michael.welzl> ok i'll do it
[16:08:31] <Wes George> thanks
[16:08:42] <michael.welzl> diff between -3 and -4
[16:09:20] <michael.welzl> diff between -4 and -5
[16:12:08] <michael.welzl> key features
[16:14:46] <michael.welzl> cnwd tracks pipeack
[16:15:32] Ryan Hamilton leaves the room
[16:15:59] <michael.welzl> why is nvp 5 minutes?
[16:16:44] <michael.welzl> updates planned for -06
[16:17:05] <michael.welzl> (not as scribe) - fyi, for folks interested in the comments from iccrg, we have made this page: http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_newcwv [http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_newcwv]
[16:18:15] <michael.welzl> next steps
[16:20:35] <michael.welzl> yuchung chen: it's common to maintain cwnd. i'd like to see if this could fix the bug in in the congestion control rfc that says the ssthresh should be based on the flightsize, not the original cwnd
[16:21:12] <michael.welzl> example: cwnd= 100. you get 95 acks. flightsize is 5 packets. then you get 3 dupacks - cwnd becomes 2, 3 or 4, just because you lost packets in the end. i think this could fix that problem.
[16:21:26] <michael.welzl> gorry: conversation with mark allman was about this particular issue
[16:21:42] <michael.welzl> it is a very real problem, but not sure if this is a part of this draft
[16:21:49] <michael.welzl> yuchung: i think it should be a part of this
[16:22:23] <michael.welzl> jana iyengar: concern: burstiness issue. this is like starting the connection again with a higher cwnd
[16:22:49] <michael.welzl> rtt could be used to pace out data just for the first rtt
[16:23:24] <michael.welzl> gorry: was already brought up by mirja in iccrg. mark allman's jump start also had some form of pacing
[16:23:48] <michael.welzl> but this is better than jump start because you at least know that the window has once worked on that path
[16:24:06] <michael.welzl> yuchung: +1 on pacing
[16:24:33] <michael.welzl> gorry: problem is, things can change significantly over time, also rtt
[16:25:42] <michael.welzl> yuchung: my point is, you have no idea and you can only base things on history
[16:26:15] <michael.welzl> mirja kuehlewind: having a max burst size might be useful. that could be adjusted based on some logic
[16:26:18] <Michael Scharf> For what it is worth: I have an old jumpstart implementation for Linux 2.6.18 or so. I could share it.
[16:26:49] <michael.welzl> gorry: draft says "maybe pacing is a good idea". problem is how to standardize pacing
[16:26:58] <Michael Scharf> (a lot of work would be needed to use it for that)
[16:27:38] <michael.welzl> jana: what we're talking about here is temporal sharing - this is related to the TCP control block interdependence draft
[16:29:20] <michael.welzl> adoption question
[16:29:36] <michael.welzl> matt mathis: this should be adopted. the choices we now have are either too aggressive or too conservative, and we should move forward on this
[16:29:50] nestor.tiglao leaves the room
[16:30:02] <michael.welzl> pasi: not sure if we should check commitment now or next time
[16:31:42] <michael.welzl> check: how many people have read and understood
[16:31:57] <michael.welzl> how many feel this is important as wg item
[16:32:06] <michael.welzl> many hands up for both
[16:32:36] <michael.welzl> jana: +1 to what matt said, should be adopted
[16:32:55] <michael.welzl> hum: unanimous in favor
[16:32:59] gorryf leaves the room
[16:33:01] <michael.welzl> of adoption
[16:33:06] michael.welzl leaves the room
[16:33:15] Andrew McGregor leaves the room
[16:33:32] wesley.m.eddy leaves the room
[16:33:52] rscheff leaves the room: Computer went to sleep
[16:33:52] wesley.m.eddy joins the room
[16:33:59] PasiS leaves the room
[16:34:03] Michael Scharf leaves the room
[16:34:13] Wes George leaves the room
[16:35:14] Alexander Zimmermann leaves the room
[16:37:40] jlcJohn leaves the room
[17:46:00] wesley.m.eddy leaves the room
[17:46:11] wesley.m.eddy joins the room
[17:54:39] Ryan Hamilton joins the room
[17:56:52] Ryan Hamilton leaves the room
[17:58:43] ena2413 joins the room
[18:01:02] Andrew McGregor joins the room
[18:05:53] rscheff joins the room
[18:13:09] PasiS joins the room
[18:13:50] PasiS leaves the room
[18:21:38] ena2413 leaves the room
[18:28:55] rscheff leaves the room
[19:06:30] wesley.m.eddy leaves the room
[19:06:41] wesley.m.eddy joins the room
[19:57:31] wesley.m.eddy leaves the room
[20:01:28] Andrew McGregor leaves the room
[20:16:26] wesley.m.eddy joins the room
[20:24:10] wesley.m.eddy leaves the room
[21:44:16] Alexander Zimmermann joins the room
[21:44:30] Alexander Zimmermann leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!