[e2e] Is a non-TCP solution dead?

Damien Phillips damphil at cs.rmit.edu.au
Wed Apr 30 00:17:40 PDT 2003


Hello,

On Tue, Apr 29, 2003 at 09:53:24AM -0400, Mark Allman wrote:
> 
> > ABC went experimental (proof that the IESG is stuck on Planet
> > Status Quo?[*]), and RFC3465 discusses concerns about the extra
> > burstiness that it introduces. Turn off delacks, and you
> > counteract some of that burstiness now you're counting acks
> > properly.
> 
> Two things...
> 
>   * First, a bit of defense of the IESG for just a moment.  I
>     requested ABC go experimental.  I'd like to see a bit more
>     experience.  While they could certainly have said "no, let's go
>     for standards track" and maybe you think they should have, I
>     just want to note that the original notion came from me.  For
>     their part, they added a "Statement of Intent" to the RFC that
>     basically says the intent is to put this on standards track.
> 
>   * IMO, turning off delayed ACKs to counteract the burstiness of
>     ABC doesn't really counteract the right kind of burstiness.  The
>     RFC discusses "microburstiness" (line rate burst in response to
>     a single ACK) and "macroburstiness" (increase in the cwnd over a
>     single RTT).  Simply ACKing every packet mitigates the
>     microburstiness -- which I don't see as a big deal with ABC (the
>     increase is 1 packet per ACK over packet counting).  But, ACKing
>     every packet doesn't deal with the macroburstiness at all.  And,
>     I think the macroburstiness is the potential problem.  While I
>     believe the spirit of VJCC is that we double the cwnd every RTT
>     during slow start the practice is that we increase by 50%.  So,
>     a remaining question in my mind is whether ABC is really
>     overly-aggressive for the network or not.

As part of research into modelling various TCP congestion control
algorithms, I have manipulated the congestion avoidance algorithm, for
use in slow start, to provide a rate of change per RTT simliar to the
rate of change of slow start with initial window of 1 MSS, regardless
of the choice of initial window. I believe this does not introduce the
"macroburstiness" you mention, for a given initial window greater than
1 MSS. The algorithm goes something like this:

cwnd(n+1) = cwnd(n) + (cwnd(n) - initialwindow + MSS)*MSS/cwnd(n)

Some quick calculations, say for initial window of 4*MSS, gives
a packets per round pattern of: 4, 5, 7, 12, 22...; instead of a pattern
of 4, 8, 16, 32, 64...; with the standard method. 

Considering ABC for the algorithm may give:

cwnd(n+1) = cwnd(n) +
           (cwnd(n) - initialwindow + MSS)*(max(bytes ACKed, L))/cwnd(n)

With an L of 2*MSS, and using delayed ACK, the pattern would
be: 4, 5, 7, 12, 21...; with the same initial window of 4*MSS. Also
if an initial window of 1 MSS is chosen, the algorithm reduces to
the standard case.

I put forward this algorithm for any remarks of viability, in
regards to reducing the "macroburstiness", resultant from a large
initial window.

regards,
Damien Phillips
School of Computer Science and Information Technology, RMIT University

> 
> allman
> 
> 
> --
> Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
> 
> 




More information about the end2end-interest mailing list