netdev
[Top] [All Lists]

Re: disabling tcp quickacks

To: Nivedita Singhvi <nivedita@xxxxxxxxxxx>
Subject: Re: disabling tcp quickacks
From: Sridhar Samudrala <samudrala@xxxxxxxxxx>
Date: Tue, 14 Aug 2001 10:45:24 -0700 (PDT)
Cc: Sridhar Samudrala <samudrala@xxxxxxxxxx>, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200108140655.XAA14160@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
I was more interested from a server point of view. After looking into
the code some more i found that tcp_listen_start() is calling 
tcp_delack_init() which is zeroing the tp->ack structure that includes
the pingpong field. 

A workaround for this problem is to call TCP_QUICKACK setsockopt() after 
the call to listen(). 

There may be some issues with the code that nivedita listed.
* tcp_incr_quickack() gets called twice.(tcp_enter_quickack_mode() also 
  calls this routine)
* we enter quickack mode and reset pingpong even when user has 
  disabled quickacks by setting pingpong to 1. 
* Can this code be replaced with a simple call to tcp_ack_snd_check()?

Thanks
Sridhar 

On Mon, 13 Aug 2001, Nivedita Singhvi wrote:

> > After the 3-way handshake is completed, i am interested in getting
> > the ack for the first request to be delayed so that it can be
> > piggybacked with the response.
> >
> > I expected that setsockopt() TCP_QUICKACK option with a value of
> > 0 will disable quickacks.
> > This should set tp->ack.pingpong to 1 and cause the ack to be delayed.
> > But looks like somehow pingpong value is reset to 0 and the ack is sent
> > immediately. What is the reason for this behaviour?
> >
> > I noticed a couple of places where pingpong can be reset to 0, for ex.
> > while sending a dupack or retransmission. But i am not sure why it is
> > being reset to 0 at such an early stage of the connection.
> >
> > Thanks
> > Sridhar
> 
> In tcp_rcv_synsent_state_process(), we have the following code:
> 
>       if (tp->write_pending || tp->defer_accept || tp->ack.pingpong) {
>                         /* Save one ACK. Data will be ready after
>                          * several ticks, if write_pending is set.
>                          *
>                          * It may be deleted, but with this feature tcpdumps
>                          * look so _wonderfully_ clever, that I was not able
>                          * to stand against the temptation 8)     --ANK
>                          */
>                         tcp_schedule_ack(tp);
>                         tp->ack.lrcvtime = tcp_time_stamp;
>                         tp->ack.ato = TCP_ATO_MIN;
>                         tcp_incr_quickack(tp);
>                         tcp_enter_quickack_mode(tp);
>                         tcp_reset_xmit_timer(sk,TCP_TIME_DACK, 
> TCP_DELACK_MAX);
> discard:
>                         __kfree_skb(skb);
>                         return 0;
> 
> If the client has disabled TCP_QUICKACKS via setsockopt()
> on this socket (i.e. tp->ack.pingpong = 1), we'll fall
> through to this code when completing the 3 way handshake
> from TCP_SYN_SENT state. However, tcp_enter_quickack_mode(tp)
> unconditionally resets tp->ack.pingpong to 0, of course.
> Subsequent acks will be quick acks, rather than delayed
> acks, as hoped. Or what am I missing here?
> 
> Does
>         (tp->write_pending || tp->defer_accept || !(tp->ack.pingpong))
> 
> make more sense? What was intended here?
> 
> Is tp->ack.pingpong not intended to store the user choice
> of "dont/do quick ack" as set by TCP_QUICKACKS? We reset
> it (pingpong) when we receive data that fills our
> out of order queue, or receive out of order/window or retransmitted
> data, so it doesnt seem to be the case..
> 
> Any clarification here would be appreciated!
> 
> On an unconnected note, why are there 2 mailing lists, linux-net
> and netdev?  Is one deprecated, or preferred?
> 
> thanks,
> Nivedita
> 
> 
> 


<Prev in Thread] Current Thread [Next in Thread>