On Mon, Feb 12, 2007 at 11:56:58AM +0000, Michael Rogers wrote: > Matthew Toseland wrote: > > I thought TCP acked an entire window at once, not individual packets? > > Every packet triggers an ack, but because of cumulative acks it's not > always possible for the sender to tell which packet arrived. If you send > 10,11,12,13 and 10 is lost, you'll get three acks for 9 because 9 is the > highest in-order packet received so far. From this you infer that 10 was > lost and fast retransmit it, at which point you get an ack for 13. :-)
Ok. No other protocol does coalesced ack's? It seems an obvious idea, for it not to be useful requires there to be a good reason not to. It's more of a problem for us because we have quite big minimum size packets, but there are other encrypted protocols.. One thing that's a minor annoyance, at least, is that if we ever want to do CBR, or disguise freenet traffic as a lossy UDP stream (VoIP for example), we'll have to have ack coalescing; this means we will have at least one more transport class (I had hoped to have very few transport classes) ... If there is a good reason to not coalesce ack's then we can do it, but generally I don't expect freenet 0.7 traffic to run on very lossy connections, and if it does, it's reasonable to expect it to be slow. What do other protocols do? Why is it not possible to get useful data on this out of your simulations exactly? > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070213/c4407b82/attachment.pgp>
