Matthew Toseland wrote: >> Unfortunately if acks can be delayed by up to 100ms for coalescing, the >> variance of the RTT will be high and consequently it will take a long >> time to detect and retransmit lost packets. > > Not if we include timestamps. Sending acks immediately is very wasteful > with the level of overhead we have.
Including a timestamp wouldn't solve the problem I described, where packets are acked out of order. When Alice finally gets the ack for packet 1 it will say "this ack was held for 100ms", but by then it's too late - she's already waited 100ms. >> For example, Alice sends packets 1, 2, 3 and 4 to Bob. She gets acks for >> 2, 3 and 4. This could mean that (a) packet 1 has been lost, or (b) the >> packets were reordered, packet 1 arrived after the others, and the ack >> is being held by Bob for coalescing. She has to wait an extra 100ms to >> find out which. > > She has to wait anyway, because the ack may be delayed. I don't understand - if you mean deliberately delayed then that's exactly my point. If you mean accidentally delayed then yes, she should take RTT variance into account, which is what I'm trying to implement. But with ack coalescing she has to wait an extra 100ms *after* taking variance into account. > 32 bytes for the HMAC. SHA-1 is broken. Its collision resistance is broken; its preimage resistance is not. HMAC relies on preimage resistance. But if you prefer SHA-256 then fine, the overhead is 52 bytes. The point remains that 52 < 1000. > It's very bad if we are encapsulating it (for e.g. stego), or doing > CBR. It also may provide an easy means to identify Freenet traffic, > unless we randomly pad it (as we do), which will increase the overhead > even more. If you're worried about the traffic looking unusual, delaying acks for 100ms is a good way to stand out - I don't know of any other protocol that does it. Having said all that however, this is only an experiment - the point of simulating it is to measure the overhead. Cheers, Michael
