On Mon, Feb 21, 2000 at 06:24:24PM +0100, Werner Almesberger wrote:
> Andi Kleen wrote:
> > Assuming 40 bytes minimum packets you could have a ~2.5MB "error window"
> > outstanding, when you use bigger packet sizes on average much more.
> >
> > Regarding (2), I'm aware of the way inetpeer id selection works in 2.3.
> > Do you have any other point?
>
> If the destination address changes, your window is much smaller, because
> a new peer ID is assigned. E.g. with 2.3.40, roughly 1.5% of the IP IDs
> repeat after 1000 packets or less, and about 10% repeat after <= 7000
> packets. (Measured over 59881 packets, each with its own destination.)
That is why I was proposing to change the IP ID back to a single global
counter, that is just added to the per peer secret. This way you look up
the peer, subtract the secret and then compare against the initial id
saved at socket creation. When packetid<initial drop it. When > 2^16
packets send set the initial packetid to 0 and don't compare anymore
(the whole point of the exercise was to catch old ICMPs from older
sockets on the same port, when the window expired we assume they have
all left the network)
>
> Now I thought the process was something like 8 bits cycle plus 8 random
> bits, but it's actually a bit more complex. So no mathematical
> explanation, sorry ;-)
When the peer is created the initial ip id is generated from the
the current time and a secret from the random device. After that the
per peer id is just increased by one like the old global counter.
The complicated fallback is only executed when it was not possible
to get a peer, that only occurs when the peer cache trashes or we
ran out of memory and is unlikely. In this case it would be ok to drop
the ICMP.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:28 EST