> 1. Internal structures are updated to handle SACK, and the stack handles > the receive side of SACK properly. (The stack advertises itself as SACK > capable, of course.) > > 2. The transmit side of SACK is implemented. > > >From what I recall about SACK, the implementation of part 1 would be > straightforward to verify and therefore easy to integrate. The send > side would, of course, require more attention, and it would be more > likely to get it if it could be reviewed seperately. I think this is a nicely methodical approach. Just being able to generate SACK blocks to the sender provides a good win for receivers. I am no kernel guru, but I don't actually imagine that it is all that tough because all the information you'd need has to be tracked now to make sure you deliver data to the application correctly. The way tougher part is that you need a new data structure (a scoreboard) to track the peer's status if you're going to do something intelligent (e.g., rfc3517) with the information you're being sent. And, you have to add hooks to update the scoreboard, consult it when sending, consult it when making congestion control decisions, etc. 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