ICCRG Notes ========== Note-Well Agenda Bashing RG Status Notes Open Issues: Who read this work? Two people raised their hands. Wes: We need more, it's a good document, feel that it's ready for last call and chairs would like to get WG consensus. Bob Briscoe: Open issues doesn't need to be perfect, don't need to be solving the issues, but just get the issues out there for discussion. Wes: Yes exactly. ===== Michael Scharf Implementation Issues and Performance of Quick-Start, Jump-Start, and other Fast Startup Approaches 20 minutes Notes on results: First plot has no packet loss... shows expected results for normal slow start and increased init window (shifts plot right). Jump start has some issues with pacing data? Tends to be moderate of all the schemes. Comparison in congestion is that Jump Start performs really well, even under higher loads - where as things like more-start at full line rate would fail. rate pacing vs increased cwnd? Off the cuff observation is that just bursting out data is worse in terms of friendliness than pacing the data out. Matt Mathis: Is most of your stuff simulation? A: No mixture of coded experiments in the kernel and simulations. MM: ISP has a lot of (diverse) machine related problems... how does this affect of the edge devices (which may have deep queues on the host, small buffers in switches, etc) How do you survey that impact and how do you figure out if it helps. (Question 2) Rate Halving is similar to __? in this examples A: [ed: didn't follow response] ===== Dirceu Cavendish Report from Slow-Start Sub-Group 20 minutes Notes: No simulation (all experimental) Gorry Fairhurst: [ed: Missed details of Gorry's initial question but it was regarding the behavior of the Quickstart algorithm] A: There is no signaling there. Set cwnd to 90% of capacity of the path. GF: How is QS so incredibly lossy, after the first adjustment it should be adjusting as normal. A: The cwnd here is kept at it's increased value GF and Tim Shepard(no-mic): That's not Quickstart A: Right, it's not exactly GF: Ok, so point made, this is not quickstart... [consensus with author made, end discussion] GF: One of the things your saying here is the need for pacing and that's why Quickstart calls for pacing in the spec. It's good to see these results verify that design goal as a good one. A: Our results don't necessarily show that exactly, could still be problems with pacing too. Wes: Was the reason for the QS approximation because of router support? A: [router] signaling wasn't there Tim Shepard: Know you don't do the first round trip communication with the router, but after that [why do you do what you do]? A: They used some estimator to keep cwnd locked TS: That's nothing like QS, what made you decide to call that QS? A: Naming is improper, but the goal is to open the cwnd to a large value, and if there's no problems keep it there. We do some reduction if losses occur. Wes: is this similar to the initial-start MS: Yes it sounds kind of like it. A: It's different than that.... [ed: missed details, but they were cut short] ===== Matt Mathis Re-thinking TCP-Friendly 30 minutes A: Asks who feels ISP shape traffic. TS: I have aDSL, uplink/downlink is shaped; stresses terminology ambiguity Dimitri Papadimitriou: What do you mean by the home LAN connected to the ISP? A: Small LAN at home connected to an ISP by small consumer grade appliance routers. David Black: Two noticable effects: One is that over time you don't get what you get over the life of a connection (ie: connection degrades due to shaping over time). Second is the asymmetric provision allocation. A: Asks who feels protected from your neighbors, other users on your own net? Iljitsch van Beijnum: neighbors aren't protected from me! A: There are some situations Bob Briscoe: Are you statically limited... BB: Draft (Flow rate fairness - Dismantling a religion) expired, TCP Friendly stuff wasn't hedged on much. A: Original stuff came off an email list BB: We've installed self policing in our heads, and not in the RFC. Crowd: So is it in the implementations? --- Start official discussion --- David Black: Got lost somewhere from the analogy to the next steps... we put the responsibility on the end hosts, yield signs everywhere. What we want to do is remove that (as some protocols ignore it now)... so where does the responsibility go to now? A: You mean I didn't say what the routers should do? DB: Yeah! BB: The network providers can do whatever they want (A: if the equipment can support it) they have the flexibility to make those policies. We do have some responsibilities too Maybe the first step is to let them do what they want, but we might not be to get ourselves out of that rat hole David Boarman: Where does the concern of fairness and congestion collapse come in. A: Internet safety evaluation, we don't really understand what properties of a protocol make it safe for others DB: How do we deal with the individual view instead of the broad view. A: Think of fair queuing... it doesn't make any difference what you do, it's all handled by the RR queuing. So the network handles it all Andrew Mcgregor: Starting thinking about what you recommend an ISP do as a default, as a lot of people and ISP trying to figure out what the defaults are. Wes: not just the ISP either. as we noted all those home devices. BB: [ed: We thought we had this figured out but don't] GF: Which comes first? Transport or Network? A: In certain specialized environments, experiment with transports. Like the LHC that would use RTCP to get it's data across. GF: A: I wouldn't go that far, if they're cascaded bottlenecks, you don't want to overwhelm the path in steady state. AM: wireless and FEC TS: How do you avoid Congestion Collapse? And DB didn't give the SACK answer... SACK makes a huge difference. A: TS: It's much harder to construct a scenario where you can form a collapse. TS: You should point out the change that SACK has introduced. Point out the good that SACK has done DB: Most home networks have high bandwidth LANs that have a small pipe to the ISP and both devices are doing bottleneck restrictions. ISP device and Home Linksys box. BB: A: Power of Re-ECN Iljitsch van Beijnum: The last few packets of a TCP connection take a loss, timeout recovering [ed: sounds a lot like limited transmit issues, missing relation] A: 2018 (SACK) one bug: There is a MUST instead of a SHOULD, Linux if you take a timeout it doesn't clear the scoreboard IV: Redescribes issue [ed: seemed to be a disconnect, conversation taken offline] WES: Do we want to work on these 3 documents A: Is this the right venue Lars: Yes I think it would be, better than tsvwg... more people interested here. Wes: Good, start with 2: Safe for the Internet? A: BB: On #2, how does it relate to who is responsible question? A: Wes: We are out of time, would like to take a poll on thoughts on working these three documents... #1) Unanimous GF: IAB Should be involved MM: I'd like it to be more baked before hand #2) Minimal - Crowd seems unsure as to goal of document Aaron Falk: Notes that this is entirely the scope of TMRG Wes: Notes that it's essentially the same people between the two groups AF: Suggests taking it there anyways #3) None - Crowd seemed to give the impression that this would be something to revisit further down the road. BB) Suggest #4 - Write a problem statement Wes, can that be the first section of the document (#1) [Lars Agreed verbally - not at mic]