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

Re: Some small remarks for REAP



Matthijs,

On 2007-06-11 18:30, Matthijs Mekking wrote:
Hello,

I looked at draft-ietf-shim6-failure-detection-07, and want to make two remarks.

1.
The draft states that "FBD works by generating REAP keepalives if the node is receiving packets from its peer but not sending any of its own." Suppose we have two hosts A and B, and A is sending payload packets to B (unidirectional). B will respond with REAP keepalive messages. But suppose a link failure occurs: A cannot receive any messages, but is still able to send. A will continue sending payload packets and might receive (delayed) keepalive messages that were triggered from payload data before the link failure. Now the payload sent after the link failure is lost without being noticed. This occurs because keepalives cannot be related to the transmitted payload.

This will not be a problem if you run a reliable protocol like TCP on top of it, because in that case TCP will fetch this problem. But if UDP is used, this remains an issue I think.

UDP is an unreliable protocol by definition, so a burst of unnotified
loss is not a protocol violation. Also, shim6 is supposed to respect the
'first, do no harm' principle - i.e. not produce *worse* behaviour than
without shim6. So while it's always a bad thing to lose packets, I don't
see this as a fatal problem.


Example scenario: Unidirectional traffic from A to B using address pair (A1, B1): ----------------------------------------------------------------------------------------------------------------------------------------
(1) A --> B: Payload1 (A1, B1)
(2) B --> A: Keepalive1 (B1, A1)
(3) B --> A: Keepalive1 (B1, A1)

Link failure (A1, B1)

(1) A --> B: Payload2 (A1, B1) (will fail)
(1) A --> B: Keepalive1 (B1, A1)
----------------------------------------------------------------------------------------------------------------------------------------


2.
How much locators will a host use? Because the Shim6 context will be garbage collected after 5 minutes (according to draft-ietf-shim6-proto-08) and with the proposed constant values, only a maximum of fifteen different address pairs can be probed. In reality, this number will be smaller, since the ULP will probably time out after two minutes. So, if only two or three locators per host are going to be used, these constants seem to work fine. With more locators, the protocol will probably also work fine, but a host will maintain locators that are probably not going to be probed. That seems a bit inefficient.

Which case do we want to optimize? A site that has a likely number of
ISPs such as two or three, or a site that for some strange reason has more?

(I don't count the case of a highly virtualized host that has many
virtual interface identifiers, because each virtual stack will
need its own shim6 context anyway.)

   Brian