TCPM meeting at IETF-97 Meeting : IETF97, Monday Nov 14, 2016, 9:30 - 12:00 Location : Park Ballroom 2 Chairs : Michael Scharf Michael Tüxen Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Jana Iyengar -------------------------------------------------------------------------- 1: WG Updates - Chairs draft-ietf-tcpm-rto-consider - Don't see much progress - Consider having an editor to address WG feedback Mirja Kühlewind: If you're interested in working on rto-consider draft, want to participate in draft as a co-author, this would be a good chance. Please let us know. draft-khademi-tcpm-alternativebackoff-ecn - May be ready for adoption call once draft-black-tsvwg-ecn-experimentation has been adopted at tsvwg David Black: We will call for adoption of the draft tomorrow and confirm it on the ML. That's the plan. -------------------------------------------------------------------------- 2: TLP + RACK performance evaluation - Yuchung Cheng Stuart Cheshire: Clarification question for Tail loss. Majority of flows don't have packet loss, but when it has, it tends to have tail loss? Yuchung: Right. Stuart: Another question. If you retransmit packet in 2 RTT, that doesn't seem to be big difference from 1 RTO + 4 x RTTVAR. Yuchung: Trick here is don't use any cap on RTT such as 1sec or 200msec. Use RTT without bound. Jana Iyengar: Comment to first question from Stuart. It's not percentage of losses, but cost of time for losses. Marcelo Bagnulo: If this is the problem for RTT boundary, why just don't remove it? Yuchung: It will cause lots of spurious timeouts. Martin Duke: Just revise slow-start might be more straightforward approach? Jana: TLP is more close to sending after a pause than sending after a loss Sending after a pause usually doesn't require reducing cwnd Stuart: You just use multiple of RTT, but it would be good to take into account variance especially for wireless network. Yuchung: Agree. We have a plan to experiment for that. Yoshi (from floor): This draft doesn't define congestion control. But, without having spec for CC, how people can implement RACK on different OSes? Yuchung: RACK is independent from CC. Yoshi: So, each implementation has its own CC for RACK? Yuchung: I guess so. Not sure, though. Some may use RFC5681. Yoshi: If we use RACK, the behavior will be way different from 5681 Yuchung: We will add some more clarification about interaction with 5681 and RACK in the draft. Bob Briscoe: TLP is an option for RACK or is it requirement? Yuchung: This is supplemental stuff, but major optimization. Bob: if you use ECN, you don't have to worry so much about tail loss. Randall Stewart: I started implementing RACK without TLP. It works well to me. Jana: RFC5681 conflates loss detection and congestion control. Separating them is not bad thing. -------------------------------------------------------------------------- 3: ECN support for TCP control packets and retransmissions - Marcelo Bagnulo Yuchung: Why retransmit packet cannot have ECN? Ilpo Järvinen: It's ambiguity problem David: I believe It's for middlebox that drops ECN packets Jana: But, if so, do we see repetitions of packet drops and retransmissions? David: Analyzing middlebox behavior is still research topic Bob Briscoe: According to your draft, it's for avoiding DoS. Not follow the logic exactly. Yoshi: The intended status of the draft is informational, is this correct? Marcelo: Sorry. It's experimental. Yoshi: I think this draft has similar situation for ABE draft. After David's draft has been accepted, we can think about adoption. Marcelo: Yes. I also would like to ask people to read the draft and feedback. -------------------------------------------------------------------------- 4: An Improvement of ECN to Enhance TCP Fairness Performance - Jennifer Cui and Marcus Sun Lars: ECN is never meant to fix the TCP's limitation you mentioned. It's better to say your scheme can also improve these issues. Jennifer: Right. Lars: If the sender doesn't have much data, it cannot utilize bandwidth fully. Why we need to care? Jennifer: It can increase the speed of expanding window size. Jana: What's the worst congested node? Jennifer: A node that marks the most amount of CE. Bob: ECN gives approximate congestion level of path, not the worst. This is not a bug, but a feature. Lars: Is this like XCP? I think what are you doing seems to be similar. Jana: Looks similar. Lars: I think you should take this to ICCRG. Motivation is ok, but looks too early to bring to tcpm. Jana: Agree as a ICCRG chair, but please take a look at XCP as it has lots of similarities. Michael Sharf (from jabber): This discussion is covered by RFC 6077. Mirja: Some of concepts in the draft are not related to ECN. You shouldn't call it ECN. Jana: Also, some signaling is not related to tcp. Might need some clarifications. -------------------------------------------------------------------------- 5: TCP Options for Low Latency: a Delayed ACK Cap and Microsecond Timestamps - Neal Cardwell Bob: I don't think the granularity of the timestamp is not defined in RFC. Neal: It actually mentions particular range for it. Brian Trammel: There is a draft which already mentioned specifying the granularity of TS Yoshi (from floor): If you use nano sec granularity, you cannot use TS for PAWS anymore. It's too short for 2MSL. Neal: Right. We are not advocating nano sec granularity. Michael ???: What's the use cases for signaling mechanisms? Neal: Some cares where you cannot upgrade every things at once. Or clients and servers are administrated by different groups. Martin Duke: What if negotiation fails? Why you don't use different option kind for this? Neal: Because we don't have space. If negotiation fails, it uses regular ms granularity. Brian Trammel: mptcp might have some hints to think about falling back. Yoshi: How does this interact with RACK? I think RACK doesn't require accurate TS. Neal: This doesn't interact with RACK for now. -------------------------------------------------------------------------- 6: TCP Control Block Interdependence - Michael Welzl Jana: ssthresh is shared in linux, but rtt isn't. I'm not sure why it is. Yuchung: there might be a bug in there. Yuchung: my concern for this draft is some parameters are not useful or negative. I might want to see more discussions why they are not promising. Key point might be the granularity for caching. dest IP base caching may not be efficient as it might be shared. Yoshi: So, do you recommend it as informational or BCP? Yuchung: I think it should be informational. Ilpo: You might want to think about caching data in the middle of the connection not only after the connection as TCP connections might be opened very closely to the same destination. Lars: We might want to say some of them are ok to be shared, some of them might be problematic for today. Michael: I agree. Yoshi: How many people read the draft? -> 2 or 3 How many people think this is useful as informational -> 10 How many people think this is useful as BCP -> none So, how about update the draft as informational? Jana: If we try to follow what Lars mention, it would be more like BCP than informational. We have to be clear what to recommended. Yoshi: It would be beneficial if we can have such recommendations. But, not sure if we can. Lars: We can do a BCP with appendix and put informational stuff in the appendix. -------------------------------------------------------------------------- 7: Increasing Maximum Window Size of TCP - Yoshifumi Nishida Yuchung: I think the question is do we expect to the need for increase very soon. Yoshi: We don't know how rapidly technologies will advance. So, answer is basically yes. Lars: I don't think it's very soon. But, it's not unreasonable to do so from now. Yuchung: A question would be if we do it, do we want to bump it to factor of 2 or 4 or more. Bob: You have to think about how do we increase it beforehand. Stuart: If you think about factor of 10 or more, it will heavily relies on timestamp option. Jonathan Looney: I agree with timestamp option approach. Mirja: I might want to see how much window size are used in today's internet. Yoshi: Sorry. I don't have such data. Lars: Some high energy physics people might want to use very large window size between their sites. Martin: Is there any middlebox interference if we use shift count 15? Yoshi: Good point. I'm not very sure. But, even if middlebox rewrites 15 to 14, it won't be fatal. Jana: If we want to change something here, I will go for 64bits seqnum. Not worth for 2X or 4X improvements.