Talk:TCP tuning

Computing: Networking / Websites Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Mid-importance).
	This article is supported by WikiProject Websites (assessed as Low-importance).

Internet Mid‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
Mid	This article has been rated as Mid-importance on the project's importance scale.

This Page

This page started from a workshop held by Internet2 on "Bridging the Wizard Gap" in Ann Arbor, MI.

Very interesting topic, I'd love to see it grow 84.47.47.221 00:06, 14 January 2006 (UTC)[reply]

Proposed Changes

I think it'd be best to separate the definition of bandwidth-delay product (BDP) topic of TCP Tuning. I'd recommend cleaning up the paragraph on BDP and then making a new entry for it. This should be linked from the BDP disambig. page and a fuller description of TCP tuning.

Note Bandwidth-delay product exists. BTW, please sign your comments. --QEDquid 08:01, 23 January 2006 (UTC)[reply]

Please refer to Talk:Internet_protocol_suite#Rwin... I added some information to that talk page because I couldn't find this page or the Rwin page very quickly. Wisepiglet 05:46, 7 December 2006 (UTC)[reply]

packet loss throughput limit

I've played a bit with the quoted formula and this simply cannot work. I don't want to suggest Mathis et al are wrong, but surely this has been quoted out of context. My assumption:

gigabit ethernet
one switch (store & forward), two hosts
MTU is 1500 bytes = 12000 bits (ACK packet is also 1500 bytes for simplicity)
Packet loss is 10^-6
Minimum RTT is 0.048 ms (12000/10^9 * 4 - switch requires zero time for MAC lookup and CRC verification)
Throughput limit should be 175 mbps ~= 21.9 MB/s - this is complete nonsense as can easily be observed. If you think that 10^-6 is a very pessimistic packet loss: while sending 83000 packets/s it means you lose one packet every 12 seconds. Why should this limit your effective throughput?

Zac67 (talk) 15:29, 29 July 2009 (UTC)[reply]

I agree - the formula is obviously misquoted. On a perfect link with loss probability almost equal to zero, the throughput diverges against infinity! I'm removing the formula; if somebody knows more about the matter, feel free to include a more plausible one. Zxb (talk) 11:16, 4 February 2012 (UTC)[reply]

The formula of course is for an additional limitation for the bitrate. It also applies only in the congestion avoidance mode, so it requires a reasonable amount of packet loss. Adding the formula back with more about its application. Alinja (talk) 16:47, 10 May 2012 (UTC)[reply]