[lkml]   [1999]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] TCP Vegas implementation available

    On Tue, 20 Jul 1999, Rik van Riel wrote:

    > Would it help for us poor PPP over analog phone folks who
    > can only use up to 1/4th of the available bandwith with the
    > current TCP stack?

    For scenarios where the performance of long TCP flows is suffering because
    traditional TCP congestion control is driving up the queues on the modem
    to the point of loss and suffering massive timeouts, Vegas should help by
    keeping queues shorter, keeping RTTs lower, and reducing loss. I've added
    some example traces of Vegas vs non-Vegas traffic over an emulated 28Kbps
    link at:

    If the losses are happening at a congested bottleneck in the middle of the
    network (say, at the local ISP's access link), then it's more complicated.
    If all the flows at the bottleneck were using Vegas then everything would
    be just groovy. But if there are any competing Reno flows, they are likely
    to erase much of the gains by filling up the queues at that bottleneck and
    keeping the loss rate high.

    I don't have direct access to any paths with the sort of performance
    problems you're experiencing. If you have sender-side tcpdump traces of
    these transfers, i'd be happy to take a look at them. Or if anyone has a
    machine that's connected often over a slow link and they can turn on their
    inetd discard service or run a netperf server, i'd be happy to run some
    benchmarks and look into this some more.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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