Subject: Re: FW: ssthressh

From: Randall Stewart <[email-masked]>
Date: Thu, 14 Jul 2005 16:56:32 -0400

Brian F. G. Bidulock wrote:
> Randall,
> 
> On Thu, 14 Jul 2005, Randall Stewart wrote:
> 
> --X-snip-X--
> 

> 
> 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.

I don't think you are required to do FR at all.. so being
more conservative is definetly not a problem :->

> 
> 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.

That probably is not really an issue either...since it is
still in the spirit of the every other packet.. only thing is
your peer may not increase its cwnd as fast.. but that probably
does not matter...

Jana was doing something else here if I remember right :-D

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

Yep...
> 
> 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.

Hmm.. interesting...

I will dig in tommorrow and see what Jana is doing.. I have my
multi-home lab setup again.. so I will see what happens with
Jana's solution...

R

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

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