Re: Some small remarks for REAP

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

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