IETF
tcpm@jabber.ietf.org
Tuesday, July 30, 2013< ^ >
jishac has set the subject to: TCP Maintenance and Minor Extensions WG
Room Configuration
Room Occupants

GMT+0
[06:44:36] rscheff joins the room
[06:46:23] gorryf joins the room
[06:48:06] <gorryf> Hi I am in this "real" room - if you are remote and can not hear the session when it starts tell me.
[06:49:16] gorryf leaves the room
[06:49:39] gorryf joins the room
[06:51:08] PasiS joins the room
[06:54:34] Yoshifumi Nishida joins the room
[07:00:35] <gorryf> Welcome
[07:05:15] <gorryf> Agenda bashing in progress
[07:10:05] g.e.montenegro joins the room
[07:12:42] Tim Wicinski joins the room
[07:15:34] <gorryf> Pasi: This is about receiver behaviour when there is no TS in a "PAWS" mode, e.g. middlebox deletes this?
[07:15:57] <gorryf> Richard: These flows can stall. For large BDP this becomes a real concern
[07:16:13] <gorryf> Pasi: There were interop issues in 3GPP
[07:16:27] <gorryf> Richard: This was a finding from a few years ago,
[07:16:37] <gorryf> Pasi: Do others have thoughts?
[07:16:49] <gorryf> Mirja: Why drop the packet?
[07:16:55] rvdp@jabber.org joins the room
[07:17:23] <gorryf> Richard: Because PAWS could take precedence and drop the packet as a pre-check before processing, some stacks do the check later.
[07:17:38] <gorryf> Mirja: Why drop the packet if the info is there?
[07:18:01] <gorryf> Richard: It could be a delayed packet - that is what PAWS was designed.
[07:18:18] <gorryf> -: I think it should have a TS, that would be more conservative
[07:18:30] <gorryf> Bob: You could use the TS if there is space
[07:18:42] <gorryf> Richard: They may use TS.
[07:19:18] <gorryf> Bob: it should be a SHOULD for an implementor
[07:19:25] <gorryf> Pasi: This is receiver behaviour
[07:20:40] <gorryf> Mirja: This is a clear SHOULD - explain if you have a history then say what happens
[07:21:18] gorryf leaves the room
[07:21:21] gorryf joins the room
[07:21:51] <gorryf> Stuart: It seems unlikely a middlebox will accept the SYN option then reject the data.
[07:22:26] <gorryf> Richard: Ah, this was to cope with middleboxes inserted by a path change.
[07:22:30] <gorryf> Stuart: OK
[07:23:03] <gorryf> Randall Stewart: MUST drop, MIST NOT abort. What happens after this change?
[07:23:36] <gorryf> Richard: Eventually it may timeout because a TS option was stripped. (Behaves as if no more packets received)
[07:24:17] rvdp@jabber.org leaves the room
[07:24:59] <gorryf> Michael Tuexen: Is there an example of a middlebox that has enough state to forward the packet, but insufficient to forwrad the option.
[07:25:44] <gorryf> Mirja: Possible this could happen. We need to explain the case clearly.
[07:27:35] <Yoshifumi Nishida> MAY send seems to have a certain interval.
[07:28:02] <gorryf> Randal:: Yes this can end in something ugly
[07:28:26] <gorryf> Mirja: I think it should be a SHOULD.
[07:29:54] <gorryf> How many people think we should keep the MUST text? (4)
[07:30:11] britram joins the room
[07:30:26] <gorryf> How many people think we take the MUST variant? (10)
[07:31:00] <gorryf> Stuart Cheshire: We need to say why this is a should - so it is celar.
[07:31:14] <gorryf> NEXT: FAST OPEN
[07:31:32] <gorryf> ----- Are there any remote participants using this log?
[07:36:02] <PasiS> gorry: yes, i can recognise at least one
[07:36:34] <Yoshifumi Nishida> I'm reading..
[07:36:34] <gorryf> Remote people: CAN YOU HEAR THE AUDIO?
[07:36:40] <Yoshifumi Nishida> yep
[07:36:45] <gorryf> Good
[07:44:48] <gorryf> Gorry at Mic: Did you say you allowed the cookie to be removed?
[07:45:04] <gorryf> Answer: No it was removed, it's now back in the draft.
[07:45:28] <gorryf> Bob Briscoe at the Mic: The turn-off is per socket not per browser - check wording
[07:45:56] <gorryf> In 6.3.1
[07:46:31] <gorryf> Michael: Socket APIFast Open is TCP specific --- MSG is not TCP-Specific
[07:46:53] <gorryf> Could setsockopt before sendto, this would follow SCTP
[07:47:48] <gorryf> Micahel Scharf: I think another update is needed.
[07:47:58] <gorryf> ... we then should be close to WGLC
[07:48:07] <gorryf> NEXT: new-cwv
[07:48:30] Alexander Zimmermann joins the room
[07:52:50] gorryf leaves the room
[07:53:43] gorryf joins the room
[08:00:01] <gorryf> Questions...
[08:00:41] <gorryf> : What I want to understand is the difference between an idle and a new connection
[08:03:09] <gorryf> If we restart a connection with cwnd=50 then this is an issue, we can send a burst of 50, why then do we have to start a new connection after 100ms - then we should collapse the window.
[08:03:38] <gorryf> Jana: We should pace the packets based on information that we do have.
[08:04:01] Juan-Pedro Cerezo Martin joins the room
[08:06:38] <Alexander Zimmermann> Since line is cutted...
[08:06:54] <Alexander Zimmermann> I agree with Yuchung comments
[08:09:07] <gorryf> Gorry (to jabber) - I think there are multiple cases here, we need to work out what to do with larger cwnds for certain.
[08:09:45] <gorryf> Gorry (to jabber): Let's see if we can meet together to get some of the key issues clear.
[08:10:02] <Alexander Zimmermann> Yes. Good point
[08:10:22] <gorryf> CURRENT TALK: RTO Restart
[08:15:54] <gorryf> Yuchung: I like the idea, and we saw a LOT more spurious retransmits.
[08:16:17] <gorryf> ... Linux has a low default RTO that may be too low for this to work well.
[08:17:22] <gorryf> minRTO may need to be changed, and see if spurious RTO is a real issue.
[08:17:39] <gorryf> Alex: This is more of a problem with Linux, than with the draft.
[08:17:58] <gorryf> ... The problem is that Linux does not implement the RFC
[08:18:12] <gorryf> Randall: FreeBSD does not follow the RFCs either
[08:18:45] <gorryf> NEXT TALK MIRJA: Accurate ECN
[08:22:38] <gorryf> NEXT: Individual drafts
[08:23:21] gorryf leaves the room
[08:24:13] gorryf joins the room
[08:24:35] Tim Wicinski leaves the room
[08:24:45] Tim Wicinski joins the room
[08:25:18] <gorryf> Questions?
[08:25:41] gorryf joins the room
[08:25:48] <gorryf> How many have read this? (7)
[08:25:51] gorryf leaves the room
[08:26:07] <gorryf> Of these people how many think this should be adopted? (8)
[08:26:19] <gorryf> Who will review this document?
[08:27:45] <gorryf> Chairs are considering this draft for adoption - and will go to the mailing list
[08:27:56] <gorryf> NEXT: TCP LOSS PROBE
[08:31:21] gorryf leaves the room
[08:31:26] gorryf joins the room
[08:33:00] Don Geyton joins the room
[08:34:48] <Yoshifumi Nishida> If it's RFC3517 or 6675, if you jsut have a few drop, it may not work well
[08:36:06] <gorryf> Michael: If we look at FEC we also need to know if these are two similar solutions
[08:36:34] <gorryf> Mirja: How often are tail losses followed by fine network paths
[08:36:59] <gorryf> 50%
[08:37:11] <gorryf> Mirja: how many are from IW bursts?
[08:37:12] <gorryf> 33%
[08:37:30] <gorryf> MIrja: Maybe we should rethink the initial window case?
[08:37:56] <gorryf> Richard: FEC and TLP address different problems. TLP is just a timer solutiom
[08:38:39] <gorryf> Jana: How many occur during idle times?
[08:39:32] <gorryf> ... assessing IW is really hard, because of the later implications
[08:39:48] <gorryf> Jana: I think we loose info when we loose the ack clock.
[08:40:10] <gorryf> ... we need to allow for a little fuzziness.
[08:40:44] <gorryf> Y: I think I need to understand the idea, a draft would be a good idea
[08:40:49] Don Geyton leaves the room
[08:41:47] <gorryf> Randal: There seems to be correlation between larger IW and the increased tail loss. A microburst of 4 packets appears safe from BSD.
[08:42:14] <gorryf> Randall: I think this needs data.
[08:42:27] <gorryf> Y: I think this is data we are looking for
[08:43:00] <gorryf> Andrew M: The front ends to web server farms have always been prone to TLP.
[08:43:12] <gorryf> ... It may be a function of buffer size.
[08:43:13] <Yoshifumi Nishida> PPR might mitigate burst.
[08:44:01] <gorryf> PRR? - do you want me to say this at Mic?
[08:44:50] <gorryf> Mirja: Is this a general problem ... ?
[08:44:58] britram leaves the room
[08:45:16] <gorryf> Randall: IW should be off by default
[08:45:35] <gorryf> Karen: There are real issues here...
[08:46:19] <Yoshifumi Nishida> may be it's too late.
[08:46:58] <gorryf> Stuart: I was listening to IW and Taildrop. If you have a max burst of 4 then you may make this worse?
[08:47:44] <gorryf> (Gorry:-> Yoshi) ... There was a big queue at the Mic... if you have comments later I'll try to realyt
[08:48:34] <PasiS> yoshi, can you send your comment to the list?
[08:48:43] <gorryf> Michael S: This needs discussion
[08:49:11] <gorryf> Michael T: I think it may be important to work also for SCTP
[08:49:40] <Yoshifumi Nishida> Hi pasi, ok
[08:49:46] <gorryf> Karren: having this work for SCTP and TCP would be useful, a fix only for TCP would still be valuable.
[08:49:57] <gorryf> NEXT: FEC in TCP
[08:50:22] <Yoshifumi Nishida> time to go... 2am..
[08:50:29] britram joins the room
[09:00:59] Sandra Murphy joins the room
[09:01:10] <gorryf> ....
[09:02:10] <gorryf> Jana: This is a change to TCP
[09:02:28] <gorryf> .. previous point is this could be done at the apps layer
[09:03:23] <gorryf> Matt: There are multicast experiences from doing FEC - including pitfalls of using sequence numbers
[09:04:24] <gorryf> Mirja: I think FEC may be a better method at the App; with a transport beneath; this is quite a big change to TCP
[09:04:59] gorryf joins the room
[09:05:22] gorryf leaves the room
[09:05:24] <gorryf> NEXT: TCP Validation (Fernando)
[09:06:01] Sandra Murphy leaves the room
[09:10:08] Dan Wing joins the room
[09:11:16] <gorryf> Michael: Do these implement the update to RF 793 - we are interested in feedback.
[09:11:27] <gorryf> ... This problem is known for years
[09:12:19] <gorryf> Fernando: The self-connect is a corner case
[09:13:08] <gorryf> Michael: In stacks we cant not check, it would be good to get feedback.
[09:13:26] <gorryf> Michael Tuesen:The other stacks could be checked using wireshark
[09:13:27] <Alexander Zimmermann> packetdrill?
[09:13:36] <gorryf> :-)
[09:14:06] <gorryf> Randal: ...
[09:14:26] <gorryf> Y: Packet Drill is a perfect tool for checking these cases
[09:15:06] <gorryf> Alex: How big is the document. Could it be an Errata?
[09:15:24] Tim Wicinski joins the room
[09:15:25] <gorryf> Michael: This is beyond an errata.
[09:15:44] <gorryf> Who is willing to review this? (Mirja, Kevin)
[09:15:44] Tim Wicinski leaves the room
[09:16:06] <gorryf> ...Reviewers should look at document and post to the list
[09:16:14] <gorryf> NEXT: ECN Fallback
[09:16:25] <gorryf> Brian Tramwell
[09:16:29] Tim Wicinski leaves the room
[09:16:56] <Alexander Zimmermann> Ok, then make  793bis :-)
[09:19:58] britram leaves the room
[09:21:31] britram joins the room
[09:21:32] <gorryf> Richard Sceff: Accurate ECN
[09:24:24] Alexander Zimmermann leaves the room
[09:24:55] gorryf leaves the room
[09:24:56] gorryf joins the room
[09:24:56] gorryf leaves the room
[09:25:48] britram leaves the room
[09:29:00] g.e.montenegro leaves the room
[09:31:01] Juan-Pedro Cerezo Martin leaves the room
[09:32:41] Dan Wing leaves the room
[09:34:20] rscheff leaves the room: Computer went to sleep
[09:53:26] PasiS leaves the room
[09:59:17] rscheff joins the room
[10:08:00] rscheff leaves the room
[10:55:57] Dan Wing joins the room
[11:01:51] britram joins the room
[11:06:50] Dan Wing leaves the room
[11:08:19] PasiS joins the room
[11:16:02] Alexander Zimmermann joins the room
[11:16:10] Alexander Zimmermann leaves the room
[11:25:34] britram leaves the room
[12:02:52] PasiS leaves the room
[12:20:13] PasiS joins the room
[13:02:23] PasiS leaves the room
[13:42:17] PasiS joins the room
[13:55:08] PasiS leaves the room
[14:21:01] PasiS joins the room
[14:21:58] PasiS leaves the room
[14:32:52] PasiS joins the room
[14:36:11] PasiS leaves the room
[14:38:45] Yoshifumi Nishida leaves the room
[15:36:27] metricamerica joins the room
[15:39:31] metricamerica leaves the room