Windows TCP TimeStamp not compliant to (RFC 1323) !?!?

Hello, I don't know if this place is the good one for a 'bug report', but I
didn't find any 'bug report' entry/email/... on Microsoft web site, so I post
here expecting my ' bug report' will be read by any Microsoft support staff

Doing some network captures to see own TimeStamp option could help
optimizing some slow transferts to some a windows server 2000/2003, I noticed
TWO bugs, the first making Windows TCP stack not compliant with RFC 1323
TimeStamp option, the second introducing some false RTT estimations (needed
by the stack to optimize the tcp windows length).
Multiple networks captures was done changing between a linux or a freebsd or
a Windows XP/2000/2003 as the 'client' computer talking to a windows 2000 or
2003 (didn't test with an XP as the server).

Here are the bugs (yes two bugs in windows 2000/XP/2003 TCP stack) for
RFC1323 TimeStamp option :

First Bug : A Linux or Freebsd system is the client (C), the Windows
2000/2003 is the server (S).
C -> send a SYN packet with TSval=<initiator_initial_value> and TSecr=0
S -> send a SYN+ACK packet with TSval=0 and TSecr=0 ????
As per RFC1323, the TSecr value to send in a ACK (even if a SYN+ACK) MUST BE
the TSval previously received, to permit the 'echo' needed by TimeStamp to
operate correctly.
The correct response MUST BE TSval=0 and TSecr=<initiator_initial_value> but
here Windows set TSecr to 0, witch is illegal per RFC 1323.

Second Bug : The XP or 2000 or 2003 is the client (C), the Windows 2000/2003
is the server (S).
C -> send a SYN packet with TSval=0 and TSecr=0
S -> send a SYN+ACK packet with TSval=0 and TSecr=0
(notice that the previous bug is masked by the client TSval set to 0, but
see next )
C -> send a ACK packet with TSval=96837 and TSecr=0
Here is the bug, the client set TSval to 96837, a very high value, that
seems to not be 'time relative' to the initial TSval=0 nor proportionnal to
the real time needed to go from the SYN packet and this ACK packet (no more
than 100ms in the real capture).
C -> send a DATA packet (exemple : an http get) with TSval=96837 and TSecr=0
This second use of the same TSval=96387, demonstrate that this value is the
real value from the 'TimeStamp clock' that is finaly used by th client (this
is the value that will be regulary incremented 'timely' as confirmed by the
frames after this one), and I suppose it should be used as the TSval value in
the SYN.
The effect of this 'big' change, 0 -> 96837 : The client Windows will
compute a 'big' RTT estimation, that will make its decision to increase its
'tcp window' size. This will slow the TCP stack to find the best 'tcp window'
for this session.
So it seems that the initial TSval set to 0 in the SYN packet is a bug.

Any 'patch' ?

(sorry for my poor english ... I'm from France)

Francis

In news35E7506-0B4A-41B6-A1EA-(E-Mail Removed),
feyb64 <(E-Mail Removed)> typed:
> Hello, I don't know if this place is the good one for a 'bug report',
> but I didn't find any 'bug report' entry/email/... on Microsoft web
> site, so I post here expecting my ' bug report' will be read by any
> Microsoft support staff
>
> Doing some network captures to see own TimeStamp option could help
> optimizing some slow transferts to some a windows server 2000/2003, I
> noticed TWO bugs, the first making Windows TCP stack not compliant
> with RFC 1323 TimeStamp option, the second introducing some false RTT
> estimations (needed by the stack to optimize the tcp windows length).
> Multiple networks captures was done changing between a linux or a
> freebsd or a Windows XP/2000/2003 as the 'client' computer talking to
> a windows 2000 or 2003 (didn't test with an XP as the server).
>
> Here are the bugs (yes two bugs in windows 2000/XP/2003 TCP stack) for
> RFC1323 TimeStamp option :
>
> First Bug : A Linux or Freebsd system is the client (C), the Windows
> 2000/2003 is the server (S).
> C -> send a SYN packet with TSval=<initiator_initial_value> and
> TSecr=0
> S -> send a SYN+ACK packet with TSval=0 and TSecr=0 ????
> As per RFC1323, the TSecr value to send in a ACK (even if a SYN+ACK)
> MUST BE the TSval previously received, to permit the 'echo' needed by
> TimeStamp to operate correctly.
> The correct response MUST BE TSval=0 and
> TSecr=<initiator_initial_value> but here Windows set TSecr to 0,
> witch is illegal per RFC 1323.
>
> Second Bug : The XP or 2000 or 2003 is the client (C), the Windows
> 2000/2003 is the server (S).
> C -> send a SYN packet with TSval=0 and TSecr=0
> S -> send a SYN+ACK packet with TSval=0 and TSecr=0
> (notice that the previous bug is masked by the client TSval set to 0,
> but
> see next )
> C -> send a ACK packet with TSval=96837 and TSecr=0
> Here is the bug, the client set TSval to 96837, a very high value,
> that
> seems to not be 'time relative' to the initial TSval=0 nor
> proportionnal to the real time needed to go from the SYN packet and
> this ACK packet (no more than 100ms in the real capture).
> C -> send a DATA packet (exemple : an http get) with TSval=96837 and
> TSecr=0 This second use of the same TSval=96387, demonstrate that
> this value is the real value from the 'TimeStamp clock' that is
> finaly used by th client (this is the value that will be regulary
> incremented 'timely' as confirmed by the frames after this one), and
> I suppose it should be used as the TSval value in the SYN.
> The effect of this 'big' change, 0 -> 96837 : The client Windows will
> compute a 'big' RTT estimation, that will make its decision to
> increase its 'tcp window' size. This will slow the TCP stack to find
> the best 'tcp window' for this session.
> So it seems that the initial TSval set to 0 in the SYN packet is a
> bug.
>
> Any 'patch' ?
>
> (sorry for my poor english ... I'm from France)
>
> Francis

Francis,
Welcome from the U.S.!

Personally, I have not dwelved deeper into RTT, however below are some links
on it that I hope will help:

Next Generation TCP/IP Protocols and Networking Components, Updated:
September 21, 2007
http://technet2.microsoft.com/window....mspx?mfr=true

Transmission throughput is less than expected for a 3G WWAN data card in
Windows Vista
http://support.microsoft.com/kb/940646

There's an email at the bottom of this link:
GetRTTAndHopCount Function
http://msdn2.microsoft.com/en-us/library/aa366013.aspx


--
Regards,
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT,
MVP Microsoft MVP - Directory Services
Microsoft Certified Trainer

Infinite Diversities in Infinite Combinations

Having difficulty reading or finding responses to your post?
Try using Outlook Express or any other newsreader, configure a news
account, and point it to news.microsoft.com. Anonymous access. It's
easy and it's free:

How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

"Life isn't like a box of chocolates or a bowl of cherries or
peaches... Life is more like a jar of jalapenos. What you do today
may burn your butt tomorrow." - Garfield

"Ace Fekay [MVP]" wrote:

> In news35E7506-0B4A-41B6-A1EA-(E-Mail Removed),
> feyb64 <(E-Mail Removed)> typed:
....
> > Any 'patch' ?
> >
> > (sorry for my poor english ... I'm from France)
> >
> > Francis
>
> Francis,
> Welcome from the U.S.!
>
> Personally, I have not dwelved deeper into RTT, however below are some links
> on it that I hope will help:
>
> Next Generation TCP/IP Protocols and Networking Components, Updated:
> September 21, 2007
> http://technet2.microsoft.com/window....mspx?mfr=true
>
> Transmission throughput is less than expected for a 3G WWAN data card in
> Windows Vista
> http://support.microsoft.com/kb/940646
>
> There's an email at the bottom of this link:
> GetRTTAndHopCount Function
> http://msdn2.microsoft.com/en-us/library/aa366013.aspx
>
>
> --
> Regards,
> Ace
>
> This posting is provided "AS-IS" with no warranties or guarantees and
> confers no rights.
>
> Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT,
> MVP Microsoft MVP - Directory Services
> Microsoft Certified Trainer
>
> Infinite Diversities in Infinite Combinations
>
> Having difficulty reading or finding responses to your post?
> Try using Outlook Express or any other newsreader, configure a news
> account, and point it to news.microsoft.com. Anonymous access. It's
> easy and it's free:
>
> How to Configure OEx for Internet News
> http://support.microsoft.com/?id=171164
>
> "Life isn't like a box of chocolates or a bowl of cherries or
> peaches... Life is more like a jar of jalapenos. What you do today
> may burn your butt tomorrow." - Garfield
>
>
>

Thanks Ace for the links, BUT I don't ask here 'how to' or 'how does 2008 or
Vista now', but I report a bug in Wndows TCP Stack on Windows 2000 (pro or
server), XP (Home or Pro), 2003 and 2003R2 server.
So your information will not help resolve the 'bug' :/
And more important, IF the bug I report is also existing on Vista and 2008,
the new features introduced in Vista and 2008 will not be able to help
resolve this bug then talking to systems that don't implement yet them but
only the 'old' TimeStamp option, and I suppose 2000/XP/2003 will not have
they tcp stack 'upgraded' with new one introducing these 'new' features, so
TimeStamp will be probable used on them too for years (and some others no
Microsoft OS too) . And remember that many of these new "enhancements" are
not normalized buut only in 'experimental' stage at IETF ...

A bug is a bug and need to be 'debuged'

Any chance to have a patch ?

Francis

In news:18C84658-8A83-49D8-9A29-(E-Mail Removed),
feyb64 <(E-Mail Removed)> typed:

> Thanks Ace for the links, BUT I don't ask here 'how to' or 'how does
> 2008 or Vista now', but I report a bug in Wndows TCP Stack on Windows
> 2000 (pro or server), XP (Home or Pro), 2003 and 2003R2 server.
> So your information will not help resolve the 'bug' :/
> And more important, IF the bug I report is also existing on Vista and
> 2008, the new features introduced in Vista and 2008 will not be able
> to help resolve this bug then talking to systems that don't implement
> yet them but only the 'old' TimeStamp option, and I suppose
> 2000/XP/2003 will not have they tcp stack 'upgraded' with new one
> introducing these 'new' features, so TimeStamp will be probable used
> on them too for years (and some others no Microsoft OS too) . And
> remember that many of these new "enhancements" are not normalized
> buut only in 'experimental' stage at IETF ...
>
> A bug is a bug and need to be 'debuged'
>
> Any chance to have a patch ?
>
> Francis

I personally am not aware of a patch. The fact no one else has responded yet
may possibly indicate there may be no "patch". Give it an extra day or two.

Also, I did provide you a link that has an email you can send with RTT
concerns. I hope that helps.

Ace

"Ace Fekay [MVP]" wrote:

>
> Also, I did provide you a link that has an email you can send with RTT
> concerns. I hope that helps.
>
> Ace
>

I didn't see the email :/ I will read again

Thanks Ace

Francis

In news:256CF959-FE5E-4CD8-ABA6-(E-Mail Removed),
feyb64 <(E-Mail Removed)> typed:

> I didn't see the email :/ I will read again
>
> Thanks Ace
>
> Francis

Just in case you missed it, here you go:

There's an email at the bottom of this link:
GetRTTAndHopCount Function
http://msdn2.microsoft.com/en-us/library/aa366013.aspx

I hope it helps you out.

Ace

hi,

I am a user of airtel broadband in india, and i am using 8MBPS plan of
airtel in my PC, but i am not getting speed higher than 2 MBPS, but when i
check that connection on Win XP, connection is running well with the speed of
7.5 MBPS.

So pls can u suggest me that is there any TCP/IP setting problem in
window2000, that it does not support higher bandwidth.

Pls reply asap.

waiting for ur reply,

In news:BA245D9F-1D1F-48D3-BF00-(E-Mail Removed),
pls revert asap <pls revert (E-Mail Removed)> typed:
> hi,
>
> I am a user of airtel broadband in india, and i am using 8MBPS plan of
> airtel in my PC, but i am not getting speed higher than 2 MBPS, but
> when i check that connection on Win XP, connection is running well
> with the speed of
> 7.5 MBPS.
>
> So pls can u suggest me that is there any TCP/IP setting problem in
> window2000, that it does not support higher bandwidth.
>
> Pls reply asap.
>
> waiting for ur reply,

You posted a response to someone else's post. I am sure you did not want to
do that, and probably more than likely, may not find your post. However if
you do, it may be something altered with the TCP win size. Normally you
wouldn't need to do this unless something has changed it in the past.

Description of Windows 2000 and Windows Server 2003 TCP Features
http://support.microsoft.com/kb/224829

Optimize the Windows TCP/IP Window Size
http://www.pctools.com/guides/registry/detail/268/

Windows 2000/XP Registry Tweaks - TCPWindowSize
http://www.speedguide.net/read_articles.php?id=157

--
Regards,
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT,
MVP Microsoft MVP - Directory Services
Microsoft Certified Trainer

Infinite Diversities in Infinite Combinations

Hello,

I know this is a very late reply, but please report bugs to Microsoft using Microsoft Connect:
http://connect.microsoft.com/

Specifically:
https://connect.microsoft.com/WNDP/Feedback





feyb6 wrote:

Windows TCP TimeStamp not compliant to (RFC 1323) !?!?
07-Oct-07

Hello, I don't know if this place is the good one for a 'bug report', but I
didn't find any 'bug report' entry/email/... on Microsoft web site, so I post
here expecting my ' bug report' will be read by any Microsoft support staff :

Doing some network captures to see own TimeStamp option could help
optimizing some slow transferts to some a windows server 2000/2003, I noticed
TWO bugs, the first making Windows TCP stack not compliant with RFC 1323
TimeStamp option, the second introducing some false RTT estimations (needed
by the stack to optimize the tcp windows length)
Multiple networks captures was done changing between a linux or a freebsd or
a Windows XP/2000/2003 as the 'client' computer talking to a windows 2000 or
2003 (didn't test with an XP as the server)

Here are the bugs (yes two bugs in windows 2000/XP/2003 TCP stack) for
RFC1323 TimeStamp option

First Bug : A Linux or Freebsd system is the client (C), the Windows
2000/2003 is the server (S)
C -> send a SYN packet with TSval=<initiator_initial_value> and TSecr=
S -> send a SYN+ACK packet with TSval=0 and TSecr=0 ???
As per RFC1323, the TSecr value to send in a ACK (even if a SYN+ACK) MUST BE
the TSval previously received, to permit the 'echo' needed by TimeStamp to
operate correctly
The correct response MUST BE TSval=0 and TSecr=<initiator_initial_value> but
here Windows set TSecr to 0, witch is illegal per RFC 1323

Second Bug : The XP or 2000 or 2003 is the client (C), the Windows 2000/2003
is the server (S)
C -> send a SYN packet with TSval=0 and TSecr=
S -> send a SYN+ACK packet with TSval=0 and TSecr=
(notice that the previous bug is masked by the client TSval set to 0, but
see next
C -> send a ACK packet with TSval=96837 and TSecr=
Here is the bug, the client set TSval to 96837, a very high value, that
seems to not be 'time relative' to the initial TSval=0 nor proportionnal to
the real time needed to go from the SYN packet and this ACK packet (no more
than 100ms in the real capture)
C -> send a DATA packet (exemple : an http get) with TSval=96837 and TSecr=
This second use of the same TSval=96387, demonstrate that this value is the
real value from the 'TimeStamp clock' that is finaly used by th client (this
is the value that will be regulary incremented 'timely' as confirmed by the
frames after this one), and I suppose it should be used as the TSval value in
the SYN
The effect of this 'big' change, 0 -> 96837 : The client Windows will
compute a 'big' RTT estimation, that will make its decision to increase its
'tcp window' size. This will slow the TCP stack to find the best 'tcp window'
for this session
So it seems that the initial TSval set to 0 in the SYN packet is a bug

Any 'patch'

(sorry for my poor english ... I'm from France

Francis

Previous Posts In This Thread:

On Sunday, October 07, 2007 7:17 PM
feyb6 wrote:

Windows TCP TimeStamp not compliant to (RFC 1323) !?!?
Hello, I don't know if this place is the good one for a 'bug report', but I
didn't find any 'bug report' entry/email/... on Microsoft web site, so I post
here expecting my ' bug report' will be read by any Microsoft support staff :

Doing some network captures to see own TimeStamp option could help
optimizing some slow transferts to some a windows server 2000/2003, I noticed
TWO bugs, the first making Windows TCP stack not compliant with RFC 1323
TimeStamp option, the second introducing some false RTT estimations (needed
by the stack to optimize the tcp windows length)
Multiple networks captures was done changing between a linux or a freebsd or
a Windows XP/2000/2003 as the 'client' computer talking to a windows 2000 or
2003 (didn't test with an XP as the server)

Here are the bugs (yes two bugs in windows 2000/XP/2003 TCP stack) for
RFC1323 TimeStamp option :

First Bug : A Linux or Freebsd system is the client (C), the Windows
2000/2003 is the server (S).
C -> send a SYN packet with TSval=<initiator_initial_value> and TSecr=0
S -> send a SYN+ACK packet with TSval=0 and TSecr=0 ????
As per RFC1323, the TSecr value to send in a ACK (even if a SYN+ACK) MUST BE
the TSval previously received, to permit the 'echo' needed by TimeStamp to
operate correctly.
The correct response MUST BE TSval=0 and TSecr=<initiator_initial_value> but
here Windows set TSecr to 0, witch is illegal per RFC 1323.

Second Bug : The XP or 2000 or 2003 is the client (C), the Windows 2000/2003
is the server (S).
C -> send a SYN packet with TSval=0 and TSecr=0
S -> send a SYN+ACK packet with TSval=0 and TSecr=0
(notice that the previous bug is masked by the client TSval set to 0, but
see next )
C -> send a ACK packet with TSval=96837 and TSecr=0
Here is the bug, the client set TSval to 96837, a very high value, that
seems to not be 'time relative' to the initial TSval=0 nor proportionnal to
the real time needed to go from the SYN packet and this ACK packet (no more
than 100ms in the real capture).
C -> send a DATA packet (exemple : an http get) with TSval=96837 and TSecr=0
This second use of the same TSval=96387, demonstrate that this value is the
real value from the 'TimeStamp clock' that is finaly used by th client (this
is the value that will be regulary incremented 'timely' as confirmed by the
frames after this one), and I suppose it should be used as the TSval value in
the SYN.
The effect of this 'big' change, 0 -> 96837 : The client Windows will
compute a 'big' RTT estimation, that will make its decision to increase its
'tcp window' size. This will slow the TCP stack to find the best 'tcp window'
for this session.
So it seems that the initial TSval set to 0 in the SYN packet is a bug.

Any 'patch' ?

(sorry for my poor english ... I'm from France)

Francis

On Sunday, October 07, 2007 9:11 PM
Ace Fekay [MVP] wrote:

Re: Windows TCP TimeStamp not compliant to (RFC 1323) !?!?
In news35E7506-0B4A-41B6-A1EA-(E-Mail Removed),
feyb64 <(E-Mail Removed)> typed:

Francis,
Welcome from the U.S.!

Personally, I have not dwelved deeper into RTT, however below are some links
on it that I hope will help:

Next Generation TCP/IP Protocols and Networking Components, Updated:
September 21, 2007
http://technet2.microsoft.com/window....mspx?mfr=true

Transmission throughput is less than expected for a 3G WWAN data card in
Windows Vista
http://support.microsoft.com/kb/940646

There's an email at the bottom of this link:
GetRTTAndHopCount Function
http://msdn2.microsoft.com/en-us/library/aa366013.aspx


--
Regards,
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT,
MVP Microsoft MVP - Directory Services
Microsoft Certified Trainer

Infinite Diversities in Infinite Combinations

Having difficulty reading or finding responses to your post?
Try using Outlook Express or any other newsreader, configure a news
account, and point it to news.microsoft.com. Anonymous access. It's
easy and it's free:

How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

"Life isn't like a box of chocolates or a bowl of cherries or
peaches... Life is more like a jar of jalapenos. What you do today
may burn your butt tomorrow." - Garfield

On Monday, October 08, 2007 7:38 AM
feyb6 wrote:

Re: Windows TCP TimeStamp not compliant to (RFC 1323) !?!?
"Ace Fekay [MVP]" wrote:

....

Thanks Ace for the links, BUT I don't ask here 'how to' or 'how does 2008 or
Vista now', but I report a bug in Wndows TCP Stack on Windows 2000 (pro or
server), XP (Home or Pro), 2003 and 2003R2 server.
So your information will not help resolve the 'bug' :/
And more important, IF the bug I report is also existing on Vista and 2008,
the new features introduced in Vista and 2008 will not be able to help
resolve this bug then talking to systems that don't implement yet them but
only the 'old' TimeStamp option, and I suppose 2000/XP/2003 will not have
they tcp stack 'upgraded' with new one introducing these 'new' features, so
TimeStamp will be probable used on them too for years (and some others no
Microsoft OS too) . And remember that many of these new "enhancements" are
not normalized buut only in 'experimental' stage at IETF ...

A bug is a bug and need to be 'debuged'

Any chance to have a patch ?

Francis

On Monday, October 08, 2007 6:10 PM
Ace Fekay [MVP] wrote:

Re: Windows TCP TimeStamp not compliant to (RFC 1323) !?!?
In news:18C84658-8A83-49D8-9A29-(E-Mail Removed),
feyb64 <(E-Mail Removed)> typed:


I personally am not aware of a patch. The fact no one else has responded yet
may possibly indicate there may be no "patch". Give it an extra day or two.

Also, I did provide you a link that has an email you can send with RTT
concerns. I hope that helps.

Ace

On Monday, October 08, 2007 6:30 PM
feyb6 wrote:

Re: Windows TCP TimeStamp not compliant to (RFC 1323) !?!?
"Ace Fekay [MVP]" wrote:


I did not see the email :/ I will read again

Thanks Ace

Francis

On Tuesday, October 09, 2007 6:37 PM
Ace Fekay [MVP] wrote:

Re: Windows TCP TimeStamp not compliant to (RFC 1323) !?!?
In news:256CF959-FE5E-4CD8-ABA6-(E-Mail Removed),
feyb64 <(E-Mail Removed)> typed:


Just in case you missed it, here you go:

There's an email at the bottom of this link:
GetRTTAndHopCount Function
http://msdn2.microsoft.com/en-us/library/aa366013.aspx

I hope it helps you out.

Ace

On Saturday, December 29, 2007 3:58 AM
pls revert asa wrote:

not getting speed in window 2000
hi,

I am a user of airtel broadband in india, and i am using 8MBPS plan of
airtel in my PC, but i am not getting speed higher than 2 MBPS, but when i
check that connection on Win XP, connection is running well with the speed of
7.5 MBPS.

So pls can u suggest me that is there any TCP/IP setting problem in
window2000, that it does not support higher bandwidth.

Pls reply asap.

waiting for ur reply,

On Sunday, December 30, 2007 1:15 PM
Ace Fekay [MVP] wrote:

Re: not getting speed in window 2000
In news:BA245D9F-1D1F-48D3-BF00-(E-Mail Removed),
pls revert asap <pls revert (E-Mail Removed)> typed:

You posted a response to someone else's post. I am sure you did not want to
do that, and probably more than likely, may not find your post. However if
you do, it may be something altered with the TCP win size. Normally you
wouldn't need to do this unless something has changed it in the past.

Description of Windows 2000 and Windows Server 2003 TCP Features
http://support.microsoft.com/kb/224829

Optimize the Windows TCP/IP Window Size
http://www.pctools.com/guides/registry/detail/268/

Windows 2000/XP Registry Tweaks - TCPWindowSize
http://www.speedguide.net/read_articles.php?id=157

--
Regards,
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT,
MVP Microsoft MVP - Directory Services
Microsoft Certified Trainer

Infinite Diversities in Infinite Combinations


Submitted via EggHeadCafe - Software Developer Portal of Choice
Adding WCF Service References
http://www.eggheadcafe.com/tutorials...ce-refere.aspx