- From: Kacheong Poon <Kacheong.Poon@Eng.Sun.COM>
- Date: Tue, 15 Dec 1998 17:48:20 -0800 (PST)
- To: Jim Gettys <jg@pa.dec.com>
- Cc: Henrik Frystyk Nielsen <frystyk@w3.org>, ietf-http-ng@w3.org
> It is the second packet drop with is a killer, not the first (due to fast > restart). If something could be done to avoid such a long timeout to > recover after a second packet drop, this would be goodness. By second packet drop, did you mean a retransmitted packet got dropped? If a retransmitted packet got dropped, it will cause a TCP timeout. But if what you meant was 2 packets got dropped in a single window, either NewReno or SACK can recover from it without causing a timeout. I think now many implementations have both. > Without real experience with deployed applications, it isn't clear what > the consequences of this fate sharing are in practice. One area it will help is because of the long train of packets, fast retransmit/recovery or SACK can be invoked to recover from packet loss. This is not true if there are only a few packets in transit, which will not trigger enough duplicate ACKs to invoke those recovery mechanisms. From TCP's point of view, this is a single stream. So all our understandings of TCP's congestion and loss recovery behaviors still apply. OTOH, if we use TCP state sharing, it is not clear how multiple streams to the same host will react to those network events. The only implementation I know of which has this TCP state sharing is from the Berkeley folks. Their simulation results look good. But since the shared state structure is accessed by all TCP connections to the same host whenever a packet is sent or received, it will not scale in real world. So I think having a mux over TCP is a better solution to your problem in the meantime. I guess this is what you guys think too... K. Poon. kcpoon@eng.sun.com
Received on Tuesday, 15 December 1998 20:51:45 UTC