Brian E Carpenter wrote:
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.
Brian is right - what would've happened _without_ shim6 in the stack would've been that A would continue to send into the void, as this is, as you describe it, a unidirectional flow. So in the case of shim6 in the stack there will still be a period before the shim6 protocol element detects the failure and attempts to repair it.
2. How much locators will a host use?
for itself or for others?For itself - as many as it has local addresses. For others then as many as it has shim6 active state for,
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.
well this timer depends on the ULP of course.
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?
the protocol as described is deliberately cautious in the way in which it manages locator exploration, and the optimisation is around the 2 - 3 locators in the a set rather than attempting to explore across a few hundred or more in a limited time..
Geoff