On Treating DUPACKs in TCP
draft-gurtov-tsvwg-tcp-delay-spikes-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Andrei Gurtov | ||
| Last updated | 2002-11-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
We suggest a more conservative management of TCP's retransmit timer and a more careful response of the TCP sender on duplicate ACKs. The former reduces the risk of triggering spurious timeouts, while the latter eliminates potentially unnecessary retransmits. Although, we believe that these suggestions are permitted (although not explicitly) by RFC2581 and RFC2988, they do not seem to be widely known nor deployed in existing TCP implementations. We therefore want to make implementers aware of these choices.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)