Brad Knowles: > Out of curiosity, can someone provide some pointers as to where SACK > really helps? Is this just for high-speed WANs and doesn't help on > LANs, or is it useful in both contexts? Also, at what speeds/packet > sizes does SACK start to become really useful? > > I'm just wondering if there aren't a lot of people who could benefit > from something like this, only they don't know it. I think that it is generally a nice addition to TCP. The space where SACK helps quite a lot is when a connection loses more than one packet From a window of data (i.e., more than one loss per RTT). Since losses tend to be bursty this happens more often than one might think by just looking at the loss rate. Without SACK, TCP can usually handle one loss per RTT with no problem (using fast retransmit). More losses, however, will cause retransmission via the RTO timer -- which is slow. Kevin Oberman: > If you don't have SACK, you need to re-transmit all of the packets in > flight within the window while with SACK, you need only retransmit the > dropped packet(s). This is not actually quite right on a couple of fronts. First, as mentioned above if you have only a single loss from a window of data then fast retransmit will take care of it without any problem. Second, TCP is not quite a go-back-n protocol even after the RTO. TCP definately resends a lot more data than it has to without SACK. But, it doesn't retransmit the entire window either. Mike Silbersack: > SACK itself really doesn't do much, it's all the new congestion > control schemes (FACK, Rate Halving, etc) that come shipped with most > SACK implementations that do the work and contain most of the > complexity. Right. (And, I'll plug RFC3517 as a very heavily vetted method for using SACK information. I am probably biased. But, I think it is very nice. I have grown to like it more and more since it was published. Its robustness keep surprising me!) allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:46 UTC