Implementation Report on
Experiences with Various TCP
RFCs
Murari Sridharan muraris@microsoft.com
Deepak Bansal dbansal@microsoft.com
Dave Thaler dthaler@microsoft.com
IETF 68 - TSVAREA
1
We did a new implementation of a
bunch of RFCs…
Started new TCP/IP stack in 2001, shipped in
Windows Vista.
Including:
• Window Scaling (RFC 1323, PS)
• ECN (RFC 3168, PS)
• DSACK (RFC 3708, EXPERIMENTAL)
• F-RTO (RFC 4138, EXPERIMENTAL)
Then we did lots of testing of the RFCs above…
IETF 68 - TSVAREA
2
Window Scaling (RFC 1323), 1/3
• Previously in Windows, but off by default
• We ran into a number of problems testing it for Vista:
– IGD problems: multiple popular vendors, popular models
• Popular vendor #1, several models having SPI block TCP
handshake with WS: automatic detection and recovery at end
system
• Popular vendor #2, models with SPI drop packets on connections
after a large scaling factor (>2) successfully negotiated during initial
handshake: no way to recover at TCP layer
– Firewall problems: multiple vendors have almost identical bug in
old versions
• Multiple popular vendors, multiple old models (one only if a nondefault feature enabled) drop packets if scaling factor > 2 has been
negotiated
• Core Issue: Broken firewall logic that does not scale window in
TCP headers correctly while determining how much data to let
through
IETF 68 - TSVAREA
3
Window Scaling, 2/3
• More problems…
– Broken websites: websites running old versions of
firewalls in front of their web servers are broken when
scaling factor > 2 is negotiated
• A more thorough testing (of over 10 million websites) has
revealed 2-4% websites impacted by this issue
– Proxy problems:
• Popular web proxy TCP splicing option (has been disabled
by default since 2006) has problems understanding the scale
factor.
IETF 68 - TSVAREA
4
Window Scaling, 3/3
• Bottom Line:
– Problems are fairly likely if used by a
consumer (not behind a proxy)
– Much less problematic if behind a proxy since
proxy may not negotiate Window Scaling
• Result: Limited to scale factor of 2 in
Windows Vista for HTTP connections
IETF 68 - TSVAREA
5
ECN (RFC 3168), 1/2
•
•
•
New for Windows Vista
Straightforward to implement
We ran into a number of problems:
–
IGD problem #1: one of the most popular versions from one of
the most popular vendors
•
•
–
When a data packet arrives with either ECT(0) or ECT(1)
(indicating successful ECN capability negotiation) indicated,
router crashed
Cannot be recovered at TCP layer
IGD problem #2: multiple popular vendors with popular models
•
•
When the 3-way handshake completes, prior to any data being
sent, router hit a bug causing further packet loss
Easily detected and recovered at TCP layer
IETF 68 - TSVAREA
6
ECN, 2/2
• Bottom Line:
– Problems are fairly likely if used by a
consumer (bad IGDs exist)
– Much less problematic in campuses and
enterprises (IGDs less likely to be present)
• Result: Turned off by default in Windows
Vista
IETF 68 - TSVAREA
7
DSACK (RFC 3708)
•
•
•
•
New for Windows Vista
Straightforward to implement
No issues yet
Now enabled by default
• Actual benefits hard to quantify to a
specific improvement in real world
IETF 68 - TSVAREA
8
F-RTO (RFC 4138)
•
•
•
•
New for Windows Vista
Straightforward to implement
No issues yet
Now enabled by default
• We have seen improvements in wireless
environments but we have not isolated the
benefits to specific enhancements
• We agree with advancing F-RTO to PS
IETF 68 - TSVAREA
9
Questions?
• Details will be at
http://support.microsoft.com/kb/934430
(not published yet)
IETF 68 - TSVAREA
10