[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shim6 and bit errors in data packet headers

Iljitsch van Beijnum wrote: 
On 4-mei-2005, at 1:33, Erik Nordmark wrote:

This is a function of how we do state management in shim6. There has been
little discussion about this. We could do soft state, where there is no
explicit taredown/close message, or we could do something which tries to
tare down the state at the both ends in a coordinated fashion.


I'm not a big fan of this. Just look at the way TCP sessions shut down. There are still many TCP sessions that end in weird ways because both ends have different assumptions. 

Agreed.

Also, it seems strange to do work because you want to end the communication.

I do this every day; need to press the hangup button on the phone (or hang up the receiver) each time I end a phone conversation.

On the other hand, we don't want to keep shim6 state around forever, and we also don't want to refresh the state continuously when there ins't any communication.

A hybrid is the thing I had in some NOID draft, and they put in HIP, which is basically a relatively long timeout (which requires periodic refresh the keep the state alive) combined with an optional CLOSE message to make the peer tare down the state sooner.
That approach is "hard state" in that it doesn't rely on an error message to recover from state loss.

The general approach of using an explicit CLOSE message to help the peer garbage collect earlier might be useful for a soft state approach, but I haven't looked into this.

So in conclusion, if we don't have a checksum for the shim6 context tag, then
we are constrained on what the shim can do when receiving a packet for
which it has no matching context.


Is there any other action that you would like to see taken that can't be without a checksum?

I don't yet know, since I don't understand the interactions with the state management.
But there is one style of recovery where the checksum might help.
When B receives a packet and doesn't have matching context state, instead of sending an error to A, B could initiate creating a new context with A.
This approach needs to be done with care to cope with DoS attacks (don't create any state on B etc). But it is an example of something which can benefit from the checksum.
However, if the mechanism can deal with a DoS attack, presumably it can deal with occasional extra work due to bit errors.

BTW if we're just worried about single bit errors you don't need a 16 bit checksum for this. Even a parity bit will find single flipped bits without fail. A very short CRC may be a good alternative.

I don't think I said "single" anywhere.
I think we need to be concerned about all in-transit errors that are not detected by the L2 mechanisms (CRC, etc).

I don't think we need to reinvent a wheel here. If we can do without checksum, then fine. If we need a checksum, just use the 16 bit one the other protocols use.

   Erik