[Iccrg] Delay-based protocol (Was: Meeting agenda (really!))

[Michele Weigle]

On Oct 11, 2006, at 3:41 PM, S. Keshav wrote:
> So, does everyone agree that future congestion control protocols  
> must be implicit, TCP friendly, and primarily
> delay-based with fail-over to a standard loss-based algorithm?

Hi all,

   In relation to the discussion from last month on delay-based  
protocols, I wanted to mention my dissertation work from UNC and put  
it up for comment.

   I developed Sync-TCP, a delay-based TCP congestion control  
protocol (the name is a misnomer -- we started with the assumption  
that both end systems had synchronized clocks, but it's not a  
requirement of the final protocol).  Sync-TCP uses TCP Reno loss  
recovery (and cwnd reductions), but also adjusts the cwnd according  
changes in one-way delay.  Sync-TCP allows a TCP flow to decrease its  
cwnd when it sees queuing delays high and increasing and to increase  
its cwnd when it sees queuing delays low and decreasing.

   I evaluated Sync-TCP (in simulation) with realistic HTTP traffic  
on both forward and reverse-paths, with multiple congested links,  
with clock drift, and with incremental deployments (Sync-TCP flows  
competing with TCP Reno flows over drop-tail routers).  HTTP traffic  
using Sync-TCP performed well (better than with TCP SACK over ECN- 
enabled ARED routers).

   A pre-print of the journal version is available at
http://www.cs.odu.edu/~mweigle/papers/comcom05-preprint.pdf

   The main goal of this work is to advance the idea that a delay- 
based protocol that adds more granularity to congestion detection  
(whether it is Sync-TCP or some other delay-based protocol) could  
actually work in a complex environment even when mixed with standard  
TCP Reno flows.

   Comments, questions?

-Michele

--
Michele Weigle
Assistant Professor
Department of Computer Science
Old Dominion University
Norfolk, VA 23539
mweigle at cs.odu.edu
http://www.cs.odu.edu/~mweigle
(757) 683-6001 ext. 5050