On Tue, 29 May 2007 23:58:39 +0300 (EEST)
"Ilpo Järvinen" [off-list ref] wrote:

On Tue, 29 May 2007, Stephen Hemminger wrote:

quoted

On Tue, 29 May 2007 23:07:00 +0300 (EEST)
"Ilpo Järvinen" [off-list ref] wrote:

quoted

On Tue, 29 May 2007, Stephen Hemminger wrote:

quoted

Since we don't invoke congestion control modules until after the SYN
handshake this is not a problem.

Just curious, do you mean that cc modules cannot measure, e.g., initial
RTT through this mechanism (though they could do that in init() cb then
I suppose)... Or do you mean that they are called already for the ACK
that completes the SYN handshake and therefore its skb is being cleaned 
from the queue right now (this is the case I above refer to)? 
In the first case the decrementer code is NOP. If the latter, then it
is just interface specification question, i.e., if SYNs are treated as 
zero or one in num_acked for the pkts_acked callback (I have no opinion
on this but was just trying to make sure cc modules get what they
expect :-)). 

We don't switch a socket out of Reno until after the initial handshake.

...It's still not very clear to me what exactly your "after" means (both 
here and in your earlier description), i.e., whether clean_rtx_queue call 
that cleans SYN skb from the queue happens before or after the switch out 
of reno or not... If I understand the code correctly, this specific 
clean_rtx_queue call happens after "your after" but I could be 
misunderstanding the current 3-way handshake code. :-)

The call to clean_rtx_queue and congestion control routine happens here:
    tcp_ack
       tcp_clean_rtx_queue
          cong->pkts_acked

Setup of congestion control happens here:
    tcp_ack
    tcp_rcv_syn_sent_state_process
      tcp_init_congestion_control

or here:
    tcp_ack
    tcp_rcv_state_process (case ack of TCP_SYN_RECV)
       tcp_init_congestion_control
     
Another benefit of this, is that when tcp_init_congestion_control is called
things like the srtt and initial sequence number have already been setup.

quoted

As an interface, it makes sense to keep the API with the SYN counting
as a packet.

Ok, this one answers the remaining question concerning the patch, here
is it without the decrementer for SYN case (which IMHO wasn't very 
beautiful looking anyway :-)).

Dave, please consider this to net-2.6. It could be a stable candidate 
as well, haven't tested yet if it applies cleanly to stable:

-- 
Stephen Hemminger [off-list ref]