[e2e] TCP and Implementation Related Questions

[Scott Johnson]

A reasonably detailed explanation of MS' Server 2003 stack is here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=06c60bfe-4d37-4f50-8587-8b68d32fa6ee&displaylang=en 
<http://www.microsoft.com/downloads/details.aspx?FamilyID=06c60bfe-4d37-4f50-8587-8b68d32fa6ee&displaylang=en>
This is in Word format.  It is also available online (readable in a 
browser).

Based on Lloyd Wood's IET link, I believe the server 2003 implementation 
will be employed inVista too.

Regards,
Scott Johnson

Lloyd Wood wrote:

> For an overview of Vista TCP features (and testing against Windows 
> Server 2003 for a geo satellite delay environment -- they didn't test 
> against anything else...), see slides and video at
> <https://outlook2003.surrey.ac.uk/exchweb/bin/redir.asp?URL=http://www.iet.tv/>http://www.iet.tv/ 
>
> 26 Jun 2006 Technology - Communications
> IP over Satcom for Military Users
> David Race and Paul Thomas
> Event: Military SatComs 2006
> (search on Microsoft)
>
> This describes Microsoft's "Compound TCP" implementation. They made a 
> big deal about having a 64K window improving the Vista stack 
> performance in that environment, as if that wasn't the obvious thing 
> to do with a 16-bit pointer on a machine with a gig of memory. See also
>
> A Compound TCP Approach for High-speed and Long Distance Networks
> Technical paper on an experimental variant of TCP optimised for 
> high-speed, long-distance networks.
> research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=940 
>
>
> Compound TCP: A Scalable and TCP-Friendly Congestion Control for High 
> Speed Networks
> <https://outlook2003.surrey.ac.uk/exchweb/bin/redir.asp?URL=http://www.hpcc.jp/pfldnet2006/paper/s4_01.pdf>http://www.hpcc.jp/pfldnet2006/paper/s4_01.pdf 
>
> http://www.hpcc.jp/pfldnet2006/slides/s4_01.pdf
>
> I expect from this that Microsoft's cwnd implementation will be 
> somewhat outside RFC specs - more aggressive? Can't find any internet 
> drafts describing it either; it seems they've not bothered with the 
> IETF. (Does the IETF still do bakeoffs, anyway?)
>
> I believe that as TCP is an ever-decreasing amount of internet 
> traffic, non-RFC changes to deployed congestion control really don't 
> matter as a threat to The State of Internet Congestion That Must Be 
> Preserved At All Costs and the Illusion that TCP Friendliness Matters. 
> But as an endhost upgrade, Windows Vista deployment will have a 
> significant effect on network performance for its userbase.
>
> L.
>
> hey, faster spam from 0wnd machines!
>
> At Saturday 22/07/2006 01:48 -0400, Salman Abdul Baset wrote:
>
>> 1) I want to confirm if Windows XP implements:
>>  a) RFC 2581 TCP Congestion Window (probably)
>>  b) RFC 2861 TCP Congestion Window Validation (not sure)
>>  c) RFC 3465 Appropriate Byte Counting (probably not)
>>
>> Does anyone know if they will be supported in Windows Vista?
>>
>> 2) RFC 2861 specified two key points
>>  a) Congestion window should be reduced after a idle period.
>>  b) Congestion window should not be increased more than the application
>>     rate if application is rate-limited or, saying it differently, cwnd
>>     should not be increased if current cwnd was not fully utilized.
>>
>>  This is an experimental RFC. Are there any updates to this? Is it
>>  recommended that all implementations should support it?
>>
>> 3) If an implementation only follows RFC 2581, then even for a
>> rate-limited application, the cwnd will keep increasing, beyond the rate
>> at which application is sending data. There are some interesting effects
>> of this phenomena for CBR traffic. To check that, RFC 2861 proposed to
>> limit cwnd increase if the cwnd was not fully utilized.
>>
>> 4) Does ns2 implement RFC 2861? I don't think so because if I rate limit
>> the application (use CBR over TCP), cwnd keeps increasing beyond the
>> application rate.
>>
>> 5) Finally, does anyone know how to get the cwnd variable in Windows? I
>> don't think this is possible using getsockopt() (Linux, TCP_INFO) but 
>> have
>> not been able to confirm the non-existence of such a method.
>>
>> Regards,
>> Salman
>
>

-- 


Regards,

       Scott Johnson

jsj at ieee.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060725/7792b024/attachment.html