netdev
[Top] [All Lists]

Re: disabling tcp quickacks

To: samudrala@xxxxxxxxxx (Sridhar Samudrala)
Subject: Re: disabling tcp quickacks
From: Nivedita Singhvi <nivedita@xxxxxxxxxxx>
Date: Mon, 13 Aug 2001 23:55:31 -0700 (PDT)
Cc: linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.21.0108131455250.1181-100000@w-sridhar2.des.sequent.com> from "Sridhar Samudrala" at Aug 13, 2001 03:02:14 PM PST
Sender: owner-netdev@xxxxxxxxxxx
> 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>