On Thu, 29 Oct 2009, Arnd Hannemann wrote:

Andreas Petlund schrieb:

quoted

Den 28. okt. 2009 kl. 04.09 skrev William Allen Simpson:

quoted

Andreas Petlund wrote:

quoted

+/* Determines whether this is a thin stream (which may suffer from
+ * increased latency). Used to trigger latency-reducing mechanisms.
+ */
+static inline unsigned int tcp_stream_is_thin(const struct  
tcp_sock *tp)
+{
+	return tp->packets_out < 4;
+}
+

This bothers me a bit.  Having just looked at your Linux presentation,
and not (yet) read your papers, it seems much of your justification  
was
with 1 packet per RTT.  Here, you seem to be concentrating on 4,  
probably
because many implementations quickly ramp up to 4.

The limit of 4 packets in flight is based on the fact that less than 4  
packets in flight makes fast retransmissions impossible, thus limiting  
the retransmit options to timeout-retransmissions. The criterion is  

There is Limited Transmit! So this is generally not true.

quoted

therefore as conservative as possible while still serving its purpose.  
If further losses occur, the exponential backoff will increase latency  
further. The concept of using this limit is also discussed in the  
Internet draft for Early Retransmit by Allman et al.:
http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-01.txt

This ID is covering exactly the cases which Limited Transmit does not
cover and works "automagically" without help of application. So why not
just implement this ID?

I even gave some advise recently to one guy how to polish up the early 
retransmit implementation of his. ...However, I think we haven't heard 
from that since then... I added him as CC if he happens to have it already 
done.

It is actually so that patches 1+3 implement sort of an early retransmit, 
just slightly more aggressive of it than what is given in ID but I find 
the difference in the aggressiveness rather insignificant. ...Whereas the 
RTO stuff is more questionable.


-- 
 i.