[Bloat] TCP vegas vs TCP cubic

[Seth Teller]

For completeness, are the commands needed to undo

   netsh int tcp set global congestionprovider=ctcp
   netsh int tcp set global ecncapability=enabled

these:

   netsh int tcp set global congestionprovider=tcp
   netsh int tcp set global ecncapability=disabled

?

On 2/2/2011 3:01 PM, Jim Gettys wrote:
> On 02/02/2011 02:16 PM, Dave Täht wrote:
>>
>> Thx. Wiki'd:
>>
>> http://www.bufferbloat.net/projects/bloat/wiki/Windows_Tips
>>
>> Is there a windows equivalent of ethtool?
>
> Dunno what command line there may be.
>
> Certainly the device driver I looked at had a UI that would let me
> control the ring buffer size, IIRC from my November experiments on Windows.
> - Jim
>
>>
>> "Richard Scheffenegger"<rscheff at gmx.at> writes:
>>
>>> For all the Windows Vista / Windows 7 Users around, they can enable
>>> "Compound TCP", which is a Hybrid TCP Congestion Control approach:
>>>
>>> netsh int tcp set global congestionprovider=ctcp
>>>
>>> and, while you're at it, also enable ECN (lossless congestion control
>>> feedback):
>>>
>>> netsh int tcp set global ecncapability=enabled
>>>
>>> If enough End Users enable ECN, core providers may be inclined to
>>> deploy AQM with Packet Marking too... And as Home Gateways are those
>>> which are prone to ECN implementation bugs, a full disconnect from the
>>> internet (rather than certain sites not reachable) is quite easy to
>>> diagnose at that end.
>>>
>>> Been running with ECN since a couple of months, and so far I have yet
>>> to encounter a site that will consistently fail with ECN. Actually,
>>> enabling ECN gives you more retries with the SYN (3x ECN+SYN, 3x
>>> normal SYN), so in a heavy congested / bufferbloated environment, your
>>> small flows might get through eventually, with higher probability.
>>>
>>> Regards,
>>> Richard
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Dave "Täht""<d at taht.net>
>>> To: "Justin McCann"<jneilm at gmail.com>
>>> Cc: "bloat"<bloat at lists.bufferbloat.net>
>>> Sent: Wednesday, February 02, 2011 5:29 PM
>>> Subject: Re: [Bloat] TCP vegas vs TCP cubic
>>>
>>>
>>>>
>>>> Thx for the feedback. I've put up more information on the wiki at:
>>>>
>>>> http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_TCP_cubic_vs_TCP_vegas
>>>>
>>>>
>>>> (At least netnews had a "C"ancel message option. Wikis are safer to use
>>>> before your first cup of coffee)
>>>>
>>>> Justin McCann<jneilm at gmail.com> writes:
>>>>
>>>>> On Wed, Feb 2, 2011 at 10:20 AM, Dave Täht<d at taht.net> wrote:
>>>>>> Can I surmise that TCP cubic is like a dragster, able to go really
>>>>>> fast
>>>>>> in one direction down a straightaway, and TCP vegas more like an 80s
>>>>>> model MR2, maneuverable, but underpowered?
>>>>>
>>>>> There are some parameters to tune, essentially setting the number of
>>>>> packets you want queued in the network at any one time (see
>>>>> http://neal.nu/uw/linux-vegas/). I haven't messed with it much myself,
>>>>> but you might try to increase those just a bit -- if Vegas
>>>>
>>>> I am reading now.
>>>>
>>>>> underestimates the queue size and the queue empties, you'll never get
>>>>> the throughput. Ideally there would always be exactly one packet in
>>>>> the bottleneck queue.
>>>>
>>>> What a happy day that would be.
>>>>
>>>>>
>>>>> But I think your results are pretty much expected with Vegas, since it
>>>>> uses the increase in queuing latency as an early congestion indicator.
>>>>> If everyone used it, we may be better off, but other congestion
>>>>> algorithms aren't fair to Vegas since they wait until there are packet
>>>>> drops to notice congestion.
>>>>
>>>> My thought was, is that if it were possible that the wireless side of a
>>>> given stack used it, life might be better on that front. Ultimately.
>>>> For
>>>> people that upload stuff.
>>>>
>>>>>> On a failed hunch, I also re-ran the tests with a much larger
>>>>>> congestion window:
>>>>> I think you mean larger send/receive buffers instead of congestion
>>>>> window? I'll bet the Vegas parameters are keeping the congestion
>>>>
>>>> Correction noted. Coffee needed.
>>>>
>>>>> window smaller than your send/receive buffer sizes, so they aren't
>>>>> limiting you in the first place, so no improvement.
>>>>
>>>> I'll take a packet trace next time I run the test.
>>>>
>>>>>
>>>>> The web100 patches (web100.org) are great for getting into the details
>>>>> of how TCP is working. If you don't want to apply them yourself, you
>>>>> can try the Live CD of perfSONAR-PS (http://psps.perfsonar.net/). It
>>>>> might be useful to have an NDT
>>>>> (http://www.internet2.edu/performance/ndt/) server running on your
>>>>> home network, or use one at M-Lab. It doesn't need much resource-wise
>>>>> but the web100 patches.
>>>>
>>>> Excellent suggestions. Building now. (It seems to want java and I don't
>>>> think the little clients I have on this testbed can handle that well)
>>>>
>>>> At the moment my little testbed is fairly flexible and my queue of
>>>> things to test is quite large.
>>>>
>>>> I have bloat-reducing patches for all the devices in the picture except
>>>> for the laptop's , which is proving to be painful to look at.
>>>>
>>>> At the moment, I'd like to be getting, useful, interesting,
>>>> *repeatable* results for a variety of well defined latency + throughput
>>>> tests with... stock firmware and then be able to re-run the interesting
>>>> series(s) against more custom configurations.
>>>>
>>>> I've only deployed the first patch on the wndr3700 thus far. It was
>>>> *amazing*.
>>>>
>>>>>
>>>>> Justin
>>>>
>>>> --
>>>> Dave Taht
>>>> http://nex-6.taht.net
>>>> _______________________________________________
>>>> Bloat mailing list
>>>> Bloat at lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/bloat
>>>>
>>>
>>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat