On Thu, Feb 08, 2007 at 09:40:39AM +0000, Michael Rogers wrote: > 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.
I don't understand. We can indicate how long a packet had to wait for coalescing, and therefore record a value based on the network delay, with a bit of the CPU delay thrown in, no? > > >> 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. Which is bad because...? > > > 32 bytes for the HMAC. SHA-1 is broken. > > Its collision resistance is broken; its preimage resistance is not. Attacks always get better. > HMAC > relies on preimage resistance. But if you prefer SHA-256 then fine, the > overhead is 52 bytes. The point remains that 52 < 1000. 52 = 5% * 1000. The probability of a packet being dropped is less than 5% on most useful links. > > > 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. Even TCP does it. Admittedly not for 100ms, but it coalesces acks. > > Having said all that however, this is only an experiment - the point of > simulating it is to measure the overhead. > > 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/20070208/48df8aaa/attachment.pgp>
