lkml.org 
[lkml]   [2001]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: TCP acking too fast
    Date
    Hello!

    > The assumption is that the peer is implemented the way you expect and
    > that the application doesn't toy with TCP_NODELAY.

    Sorry??

    It is the most important _exactly_ for TCP_NODELAY, which
    generates lots of remnants.


    > Not really. You could do one of two things: either ack every second
    > segment

    I do not worry about this _at_ _all_. See?
    "each other", "each two mss" --- all this is red herring.

    I do understand your problem, which is not related to rcv_mss.
    When bandwidth in different directions differ more than 20 times,
    stretch ACKs are even preferred. Look into tcplw work, using stretch ACKs
    is even considered as something normal.

    I really commiserate and think that removing "final cut" clause
    will help you. But sending ACK on buffer drain at least for short
    packets is real demand, which cannot be relaxed.
    "final cut" is also better not to remove actually, but the case
    when it is required is probabilistically marginal.

    Alexey
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:08    [W:0.023 / U:61.484 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site