Hi,
I have a question regrading the TCP implementation. I
am not subscribed to this list, so please cc your
response.
In the present TCP (2.5.x) implementation, the TCP
sender never exits TCP_CA_Loss state until all packets
upto high_seq are acknowledged. But lets say while
doing retransmissions, some packet less than high_seq
are lost again. Ideally the TCP sender should just
enter fast retransmit and fast recovery, but from the
present implementation it seems the only way to come
out of it is after a timeout.
Could somebody explain this to me please.
Thank you very much.
Best Regards
--SPY
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
On Wed, 2002-07-17 at 19:18, spy9599 wrote:
> In the present TCP (2.5.x) implementation, the TCP
> sender never exits TCP_CA_Loss state until all packets
> upto high_seq are acknowledged. But lets say while
> doing retransmissions, some packet less than high_seq
> are lost again. Ideally the TCP sender should just
> enter fast retransmit and fast recovery, but from the
> present implementation it seems the only way to come
> out of it is after a timeout.
>
> Could somebody explain this to me please.
The only reliable way to detect that a retransmitted segment has been
lost is timeout. You can't use dupacks, because at this point they are
not necessarily caused by lost retransmissions. They might be caused by
duplicates, delayed packets, or the acks themselves might be delayed.
You could end up with shrinking the congestion window unnecessarily or
just plain bad retransmission behaviour. Note that if SACK is enabled,
the transmitter will not retransmit too many unnecessary segments
anyway.
MikaL
Hello!
> are lost again. Ideally the TCP sender should just
> enter fast retransmit and fast recovery,
While retransmitting after timeout and until all the segments sent
to the time when retrasmit started, fast retransmit is prohibited
by Floyd's block. Look into RFC2582 for explanations, keyword is "send_high".
Alexey