Subject: Re: FW: ssthressh

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Jul 2005 12:34:05 -0600

Randall,

On Thu, 14 Jul 2005, Randall Stewart wrote:

--X-snip-X--
> 
> A question  or two below...
> 
> > Characteristics of the CMT algorithm that might assist with this are as
> > follows:
> > 
> > * When I go to transmit, I select the "best" destination based on a
> >   weighting that includes available send window considering congestion.
> >   This causes lower performing destinations to fall away.
> > 
> > * The weighting also favors the same destination as was last transmitted
> >   to if all other weighting factors are equal.  This adds persistence on
> >   the same destination.  This is good for limiting gap reports as well
> >   as helping with the bottleneck behavior.
> > 
> > * Once I choose the best destination, I send a much data as possible (is
> >   available), without checking again.  Again, this is good for gap
> >   reports as well as bottleneck behavior.
> 
> So you fill the destination completely until flightsize >= cwnd?

Yes, as long as there is still data to send.

> > 
> > * When sending to the "best" destination is no longer possible because
> >   the send window has closed, I rerun the selection algorithm and go
> >   again.  (In the loop consideration is also given for max burst.)
> 
> So does this mean that when you perform the previous step.. and your
> cwnd is full to the "former best destination", then you run your
> selection algorithm and pick a new "best" one that has space
> in its cwnd... and then repeat?

Yes, as long as there is still data to send.

> 
> 
> > 
> > If you adjust your own CMT algorithm to similar characteristics, you
> > might very well be able to recreate my bottleneck results with your own
> > systems.  It shouldn't be too hard for someone to run an NS-2 simulation
> > to figure out just what is happening and the importance of some aspects
> > of the algorithm.
> > 
> 
> Jana is working on the CMT algorithm .. he has asked me to test it
> and I think I will finally get a chance this week to turn it on and
> see how it does... I don't think he has implemented any of the
> algorithms you enumerate above... maybe he should :-D
> 
> I will first test what he has put into the CVS base... and then
> we will need to think about making some adjustments accordingly :-0

If you place some persistence on the "best" destination into the
algorithm, you might not only find the bottleneck behavior similar to
what I report, but you should find that the gap report generation at the
receiver reduced.

You could also try my two tricks for gap reports on CMT:

1. When the sender gets a gap report, I only perform FR steps when the
   receiver is not "making progress".  The receiver is "making progress"
   when it is contigiuosly filling a gap.  That is, a gap is shrinking.
   This is far simpler that trying to run a multiple queuing model.
   This trick does not break the rules: one is allowed to be more
   conservative than the FR rules allow, per RFC 2960.  I don't think
   one really has to even do FR, however, it has great benefits.

2. This second one breaks the rules, slightly.  It is at the receiver.
   Normally one SACKs every second message, and sends withheld SACKs
   within a timeout (200ms) if there is no received data to trigger a
   SACK.  The purpose of this, of course, is to keep the ack clock
   running.  I still apply these rules, however, I do not send a SACK
   every second received packet iff there is already more received data
   to process in the receive queue.  That is, I send one SACK for an
   entire continguous block of packets in queue, rather than many SACKs,
   filled with many gap reports.

3. I perform Nagle's algorithm with Minshall's modifications.

Those two tricks are the key to providing performance similar to what I
reported.

The first (and legal) one is more important than the second (illegal)
one.  The second one provides that %0.5 boost over TCP, which was
non-SACK TCP on that version of Linux and its acking like crazy at the
top end.

--brian

> 
> R
> 
> -- 
> Randall Stewart
> ITD - Cisco Systems Inc.
> 803-345-0369 <or> 815-342-5222 (cell)

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦