ICCCRG met late Tuesday afternoon 1 - went over agenda 2 - RG documents: - bibliography of congestion control RFCs - new version to be released soon - open issues document - early version released 3 - Dimitri Papadimitriou - Open Research Issues - describe problems in congestion control - increasing heterogeneity challenges existing techniques - departing from pure stateless model - list of challenges - router support - implicit vs. explicit feedback Aaron Falk: making Tim Shepard's point, discussion should be in terms of "queues" rather than "routers", some things that are queueing packets aren't routers - keeping state Tim Shepard: reminded about Aaron's point Mark Allman: in quickstart, it's hard to identify if all queues along a path actually implement some functionality Bob Briscoe: typical to surround dumb lower layer equipment with more intelligent equipment to protect it - information needed by routers - questions on feedback signals - dynamic range of requirements Aaron Falk: question about dynamic range vs dynamics - dynamic range is that much larger and smaller link capacities can be found; I don't see that on there, not time-varying, nature of network is broadening - dealing with corruption loss Bob Briscoe: just posted a draft to TSVWG on packet marking with ECN, if you have a resource that can be congested by packets and another by bits, you treat that in different ways - small packets Bob Briscoe: also increasing range of packet sizes, bigger and bigger ones mixing in with the smaller ones - tdm over pseudo-wires - multi-domain - precedence of elastic traffic Dave Thaler: tunnels create nested congestion control, not sure if this is part of the existing challenges or a new one - misbehaving senders - should be "misbehavior" - Bob Briscoe pointed out that more than just a receiver can misbehave - need to discuss all more on mailing list 4 - ietf experimental proposals - different types of experimental (broad Internet vs closed private network scope - IETF decides what will be published, ICCRG just helps decide what can be called safe Aaron Falk: RG doesn't specify applicability, but rather evaluates the author's claims Lars Eggert: result will be a review, from looking at papers and documentation, it then moves to transport area in ietf; text is needed, but format doesn't matter, should go to ADs, authors, WG chairs Mark Allman: also public, not inventing secret process right? Lars: posting to ICCRG is totally fine - evaluate each proposal on its own, some guidelines in tmrg and tsvwg documents - timeline should be fast, 4 months - first proposal is compound tcp Lars: proposal format should be internet-draft that can stand on its own, gather details together from various research papers Aaron: RG needs to review internet-drafts Lars: RG can decide what inputs format it wants 5 - Murari Sridharan - Compound TCP - IETF to consider for experimental RFC - design goals - efficiency, fairness, stability - loss and delay-based components added together - vegas-like; binomial-increase, multiplicative decrease - only differs from standard tcp at cwnd > 38 Tim Shepard: cwnd + dwnd ... if loss is detected you want cwnd + dwnd to be halved or cwnd? Murari: the total window (the sum) is halved - response function - similar aggressiveness to HighSpeed TCP unknown: can you compare response function with BIC/CUBIC? Murari: CUBIC draft is also there, we compare only to HighSpeed - convergence and RTT fairness improved over Reno - choosing gamma parameter unknown: what's the effect of running over a link-layer that has variable delay? Murari: one thing that protects us is that delay window can go to zero and fall back to standard TCP Allman: comment, but not about CTCP, about deathmatches. Is comparing performance in-bounds for this group Wes: it is in bounds, open discussion on mailing list, but out of context of reviews for IETF Murari: most algorithms start out with certain design goal, compromising on one parameter to optimize another, so comparisons Shepard: is it safe to deploy A: yes, and is it safe to deploy B: yes, but what about A+B Wes: that's in our open issues, it is definitely something for the IETF Shepard: it's a complex matrix Lars: we need to watch this, we're not doing "turn this on and forget about", when we have a lot of data, we can come back and pick a proposed standard 6 - Cesar Marcondes - Congestion Control Research at UCLA - TCP Libra - RTT fairness, motivation and previous work - basic description of Libra algorithm, derived from control-theoretical point of view, two new terms, fairness control and scalability control - equilibrium properties, linear, perfect, and libra RTT fairness - dumbell topology, cross-traffic - parking lot topology - TCP Evaluation Suite - all about death matches - comparing differences of protocols and how they behave together - reproducible simulation environment - graph analysis - available for download http://netlab.cs.ucla.edu/tcpsuite Wes: this could be helpful to us in determining safety Mark Handley: every time I've run simulations, I've suffered from phase effects, how do you handle that Cesar: every link has an RTT, obtained from exponential distribution, flows have different sizes and starting times unknown: Injong is trying to do something similar, can you guys agree on some points? Cesar: haven't talked to him about it Lachlan Andrew: we have a similar lab, just down the street from you, but we're using real equipment 7 - Vijay Subramanian - Balancing Loss Tolerance Between Link and Transport Layers in Multi-Hop Wireless Networks - multi-hop NLOS MANETs and meshes - protocol objectives - goodput at link and transport with low latency at link layer - LL-TCP, LL-HARQ - protocol framework - proactive and reactive FEC - achieving balance between link and transport layers - single-hop and 4-hop simulations - major improvements over standard TCP - file-transfer latency - faster than SACK - openbsd implementation 8 - Dirceu Cavendish - Lossless Congestion Control - not possible without router support - want a protocol that avoids packet loss using delay-based control - delay-based review, setting operating points - lossless requirements and candidates - high throughput without packet losses, Leith07 and Cavendish07 - TCP-CCP - capacity and congestion probing - parking-lot simulation - transoceanic experiments - welcome participation from ICCRG in next steps