TBIT, the TCP Behavior Inference Tool
-
Papers:
-
Jitendra Padhye and Sally Floyd,
Identifying the
TCP Behavior of Web Servers.
June 2001, In Proceedings of SIGCOMM 2001.
Or the earlier ICSI
Technical Report 01-002,
February 2001.
-
Measuring the Evolution of Transport Protocols in the Internet
(postscript,
PDF).
Alberto Medina, Mark Allman, and Sally Floyd.
Computer Communications Review, April 2005.
-
Measuring Interactions Between Transport Protocols and Middleboxes
(postscript,
PDF).
Alberto Medina, Mark Allman, and Sally Floyd.
Internet Measurement Conference 2004, August 2004.
-
Talks:
-
Jitendra Padhye,
On Inferring TCP Behavior (PDF),
SIGCOMM 2001, San Deigo, CA, August 2001.
-
Jitendra Padhye,
TBIT: TCP Behavior Inference Tool (PDF),
NANOG 20, Washington DC, October 2000.
-
Alberto Medina,
Measuring the Evolution of Transport Protocols in the Internet
(PDF),
Boston University and BBN, Boston MA, May 2004.
-
Code:
-
The alpha release of the 2001 and 2003 TBIT code is available from
the tbit-0.6.tar.gz
, tbit-0.6.1.tar.gz tar files.
This code is no longer supported.
-
A patch for tbit-0.6 for Linux 2.4 is available from
the
tbit-0.6-ru.diff.gz diff file,
from Heimir Thor Sverrisson at Reykjavik University.
-
The revised 2004 code for tbit 1.0 is available from
tbit-1.0.tar.gz.
- A
patch
to tbit 1.0 to fix some warnings on tbit and make it work on
Linux (except for the ECN test).
From Baruch Even.
-
TBIT modifications added by Sushant Rewaskar.
More documentation will be available later.
-
URL Lists:
-
February 2004 (download)
-
The 2001 list of web servers:
Some of the 2001 results are based on list
of web servers provided to us by Dax Kelson. The SRVER
ID tag in the HTTP header identifying the server software.
- Related work:
-
A. Langley,
Probing the Viability of TCP Extensions,
September 2008.
"We find that 9.08% of
hosts don’t respond to SYN frames with payloads, 0.17% of
hosts don’t respond to SYN frames with non-standard op-
tions and 0.56% of hosts don’t respond to SYN frames which
attempt to negotiate ECN."
-
R. Fonseca, G. Porter, R. Katz, S. Shenker and I. Stoica,
IP Options are Not an Option, Technical
Report UCB/EECS-2005-24, December 2005.
"We discovered that approximately half of Internet paths drop packets
with options....
with the vast majority of those drops occurring in edge AS networks.
Furthermore, these drops are concentrated in a minority of the ASes."
-
Sourabh Ladha et al,
On the Prevalence and Evaluation of Recent TCP Enhancements.
Globecom 2004. IEEE, Vol. 3, pp. 1301-1307.
"We consider five TCP enhancements: (1) selective acknowledgements
(SACK) and the SACK-based loss recovery algorithm; (2) increasing
initial congestion window; (3) limited transmit; (4) appropriate byte
counting; and (5) early retransmit."
-
Synscan - A TCP/IP network testing tool and active OS fingerprinter.
Synscan tests the congestion control mechanism, the DF-bit, the
initial sequence number, the default TTL, and RTO values. Synscan
tests the response to odd-length fragments and the method for
setting the initial window. Synscan also tests the remote TCP
implementation's methods for setting the MSS option,
the timestamp option, and the window scale option.
-
IP personality:
"The primary objective of this patch is to counter network
fingerprinting techniques."
IP Personality can change the TCP initial sequence number,
initial window size, and TCP options in packets.
-
Some May 2003,
June 2003,
July 2003,
and
August 2003 results on a small list of web
servers. Scripts for the May-July tests.
-
Starting in August 2003 we have written some python scripts to execute the TBIT tests
as well as new non-TBIT tests from a common execution "interface". The structure and use of this
script is explained in the README file.
-
NewReno, Reno, and Tahoe:
-
Identification of TCP implementations
at popular web servers, from July 2000.
This test is decribed in Section 2 of [PF00].
-
Tests from July 2000 to determine if servers classified
as "Tahoe without Fast Retransmit" would invoke Fast Retransmit when only
one packet is dropped from a window of data. This test is described in
Section 4 of [PF00]. The lack of Fast Retransmit in these cases was determined
to be due to a problem in the TCP implementation which is now being fixed.
We were originally told that the fix should be in Windows 2000 Service
Pack 2, but now we are told that it will appear in Windows 2000 Service
Pack 3, which, when it appears, should be listed on the
Windows
2000 Web Page. Another possibility is to contact Microsoft
Support directly.
-
Conformant congestion control?:
These tests test whether the TCP sender halves the congestion window
in response to a packet drop. The results
from October 2000
show that, of 6485 web servers tested, 72 (with the following SRVER
ID tags) reduce their congestion window from 800 bytes to only 700
bytes after a loss. We did not find any web servers that did not reduce
their congestion window at all after a loss.
-
ECN.
-
Initial windows:
Initial windows (with an MSS of 100 bytes)
used by web servers in October 2000. For web servers with initial windows larger than two
packets, we also found the
initial windows
with an MSS of 512 bytes (October 2000).
A few web servers used initial windows as
high as 17 packets in this case.
RFC
2414 allows initial windows of at most four packets, regardless of
the packet size in bytes.
-
SACK:
Our old results (October 2000) showed
that many web servers that claimed to be SACK-capable didn't seem
to actually use the information in the SACK blocks. This is no longer
the case in our newer results (April 2004).
-
TBIT Tests about deployment of TCP mechanisms, listed by RFC.
-
Tests implemented or in progress in
TBIT Extensions by Sourabh Ladha:
- Deployment of Limited Transmit, Early Retransmit
- Deployment of Appropriate Byte Counting.
- Support for the Window Scaling option.
- Deployment of FRTO.
- Deployment of the Eifel detection algorithm.
- Deployment of ECN-nonce.
- Value of the dupack theshold?
- Value of advertised window (a_rwnd)?
- Value of the advertised MSS (Default and Maximum)?
- Retransmit timeout values:
- Exponential backoff of the RTO?
- Slow-start after a retransmit timeout?
- RTO when the SYN packet is dropped?
- Value of Max.Retransmit (R2-SYN and R2-data)?
New TBIT tests that we report on in our May 2004 paper on
"Measuring the Evolution of Transport Protocols in the Internet"
(listed at the top of this page).
- SACK:
- Deployment of the DSACK option.
- Are middleboxes translating TCP sequence numbers but forgetting to
translate the sequence numbers in SACK blocks?
- Congestion Window Validation:
- Limiting growth of the congestion window during an application-limited
period?
- Retransmit timeouts:
- the minimum RTO.
- The minimum MSS.
- Slow-start?
- Initial congestion windows:
- For servers that use initial congestion windows of four segments or
higher, is the packet drop rate different when the servers are
restricted to lower initial windows?
- Problems with SACK blocks, possibly from middleboxes along the path?
- Problems with IP or TCP options?
- Does path MTU discovery work to each web server? Or is it blocked somewhere
along the network path?
- Testing for reordering on the path to and from the server.
- What about reordering as a function of packet size?
TBIT tests on the wish list:
- Congestion Window Validation:
- Reduction of the congestion window after an idle period?
- Are there any TCP implementations out there that use Vegas algorithms?
- Tests with scenarios specifically designed to illustrate some of
the bugs or bad design decisions in some of today's TCP implementations.
(Acknowledging that there would also be the question of whether these particular
artificial scenarios are of concern or not.)
- Retransmit timeout values:
- TCP clock granularity?
- Are there other useful tests comparing performance when
the web server's behavior is varied (e.g., in response to the receive
window, the MSS, etc.)?
- Are there other useful tests looking for the effects of middleboxes
on TCP performance (e.g. blocking ECN, blocking PMTU discovery, blocking
unknown TCP or IP options, modifying TCP packet headers, etc.)?
Possible tests for testing TCP implementations at clients:
- Passive tests: Does the client send fractional acknowledgments?
- Active tests: Most of the general TBIT tests for servers would fall
in this category.
More answers to
the following questions:
-
What fraction of bytes/packets/TCP-flows in the Internet are SACK-capable?
-
What fraction of the non-SACK TCP flows in the Internet use NewReno instead
of Reno congestion control mechanisms (and thereby avoid unnecessary retransmit
timeouts when multiple packets are dropped from a window of data)?
Other TCP test suites?
This material is based in part upon work supported by the National
Science Foundation under Grant Nos. 0205519.
Any opinions, findings and conclusions or recomendations expressed in
this material are those of the author(s) and do not necessarily reflect
the views of the National Science Foundation (NSF).
Last modified: September 2008.
Thanks to Sourabh Ladha and Jitu Padhye for contributions to this
page.