DRAFT minutes of ICCRG meeting @ IETF 78 Friday 30 July 2010, 9:00-11:30 in 0.2 Berlin Title: RG Status Presenter: Chairs Time: 10 minutes Title: "MulTFRC update (draft-irtf-iccrg-multfrc-00.txt)" Presenter: Michael Welzl Time: 10 minutes (no comments) Title: "News from CAIA's newtcp project -- delay-based TCP and improved instrumentation of FreeBSD's TCP stack" Presenter: Michael Welzl (on behalf of CAIA) Time: 10 minutes Fred Baker: the Cisco funding was me. Reason is really the LEDBAT question: how do I move a whole lot of data through the network without destroying the ISP. Secondly, using high-loss radios in things like 6lowpan, COAP where loss-based TCP really has a problem. Idea is to tune to the knee instead of the congestion decay cliff, so we can get fair sharing without attacking the network. Therefore I'm very interested in congestion control that achieves this. I asked one of the Contiki authors what their CC is, and reply was there is only one buffer and therefore there cannot be congestion. Lars -> lawrence: please tell me you are leaving the default in BSD at NewReno Lawrence Stewart -> Lars: Absolutely Title: "TCP modifications to reduce thin-stream latency" Presenter: Andreas Petlund Time: 20 minutes q: Do you have measurements on extra transmissions? a: Answer is in the slides: about 6 to 10 % q: Thin streams are <4 packets in flight, so all streams are thin at the beginning? a: Yes q: Bundling... when you send the second packet, how many bytes do you have in flight? a: We're not tracking that q: What about the congestion window? a: That neither, which is work to be done. Gorry: We're interested in streams that vary between thick and thin, so let's talk later. Title: "Seeding TCP retransmission timer using SYN/SYNACK RTT sample (draft-ycheng-tcpm-rtosynrtt-00.txt)" Presenter: Yu-chung Cheng Time: 15 minutes Gorry: Analysis is on fixed lines rather than wireless? a: Usually on those links the SYN RTT is higher, but could be lower. q: The SYN RTT on wireless can in fact be much higher, but it seems the estimator could be too high based on this. a: We could clamp to 3s. q: You have this 'd' in your formula representing delay for two packets, should you change this if the IW is 10 packets? a: TCP typically acks every other packet, so the first ack is usually after receiving two packets. q: 2988 says reset the timer after each ack, but stack may sample only per window. What are the implications? *** add-onfrom Jerry Chu: A question was raised (by someone from Nokia I think) during the "Seeding TCP retransmission timer using SYN/SYNACK RTT sample" presentation on the impact of the IW=10 proposal on the RTO calculation. My answer was that according to RFC2988, the retransmission timer will be restarted after each ack that acknowledges new data. Hence the RTO only needs to cover 2 pkts plus the possible effect of delayed acks, but not the whole window. A follow-up question was asked on the impact of those stacks that only take one RTT sample per window. After some thought I realized the frequency of the RTT sampling does not directly affect the validity of the RTO calculation proposed here. It's the frequency of the acks that matters. Hope this answers the question. *** Title: "Scaling IW with Internet scale" Presenter: Matt Mathis Time: 10 minutes Fred Baker: How do you expect clients to know the link buffer space? A: They do in some cases. Bob Briscoe: 83 SYNs for multiple objects? A: I didn't dig through, but there were 83 SYNs Bob: Parallel for the same object? Tim: 83 immediately? Matt: I didn't check how many were cascaded. Carsten: I usually see 30-40 objects in 3-5 waves, later waves delayed by download of earlier. Matt: I've spoken to these developers (both browser and site developers) and they do it for latency... deliberately. Costin: A lot of these connections are there for pipelining your local link... Matt: Which is why it is reasonable to have some parallelism, but not that much. Aaron: What's a 'slow' link? Matt: Coming to that Bob: Problem here is, buffer size is getting smaller, based on long flows. Matt: Those analyses are for highly aggregated links, though. Bob: That analysis across both small and large numbers of flows is supposed to decrease for faster links, but to optimise startup you need more buffer. Slow links are mostly NOT SHARED, and have only a couple of segments worth of buffer. IW=3 is too big then. Aaron: You're saying that there is only dumb queueing? Matt: I'd hope not, but the paper I read did not say. Content developers go to a lot of trouble to spread assets across servers. Bob: Isn't that the same however you have multiple IWs at the same time. Title: "A Simulation Study on Increasing TCP's IW - Preliminary Results" Presenter: Ilpo Jaervinen Time: 30 minutes Bob: This is a useful presentation to give some intuition as to what happens. What sort of queues were you using? A: Tail drop Bob: I think the results would be very different with a different kind of queue. Jana: Do you have an insight as to why the fairness between bursts goes down at IW=10? Richard: What kind of stack and congestion control? A: This is ns-2, its defaults. Title: "Increasing TCP's Initial Window (draft-hkchu-tcpm-initcwn-01.txt)" Presenter: Nandita Dukkipati Time: 45 minutes Fred: What was the impact on sessions competing with yours? In other words, have you completely blasted the rest of the world off the network? A: We can't completely answer that. --- new speaker Jana: TCP latency is transfer completion time? A: Latency is time from first byte leaving to last byte acked Costin: Why is there a dip at 60kb? A: There are always some proxies, and there was a particular site skewing the data. Richard S: You're investigating long links, high RTT, what happens if you run at very short RTT? A: We also studied that, but didn't really see anything interesting. Q: Did you see initial timeouts increase? A: Somewhat, there is a slide on that. Q: Are you using a linux stack? A: Stock linux stack Q: That stack is unique in retransmission recovery. A: We're using a stock stack. Q: That should be noted. Bob: It would be better to come with the question 'what should IW be?' Nandita: Should we be trying to find a global for the internet? Lars: This is a TCPM proposal. We'd like to come with a proposal for standardising. Nandita: It's a great research question. Jana: Thanks for doing all this. I suggest that 'offered load' is too coarse a metric, we can talk about ways of doing something more realistic. Nandita: For sure... offered load >1 is unstable. Do you have any real traces?