Re: CUD and FBD

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 06/10/2005, a las 22:21, Jari Arkko escribió:

> marcelo bagnulo braun wrote:
>
> > So, in FBD each node has a clear view about a failure in their 
> > incoming path, while in CUD, each node can detect a failure but it is 
> > not certain of which direction is affected.
> >
> > This difference may not be relevant, depending on which are the 
> > following steps.
> > In FBD, the node that has detected the outage needs to inform the 
> > other end about the failure, in a reliable manner. This may result in 
> > starting the full path exploration procedure as described in the 
> > draft, so that the other end starts the procedure itself.
> > In CUD, the behaviour is likely to be the same, since the node that 
> > has detected the outage does not knows which direction has failed, so 
> > both nodes need to perform the full path exploration procedure.
> > So, i think that the result in both mechanisms is similar.
>
> Agreed.
>
> > - Overhead
> >
> > In CUD, each time there is an idle period, 2 packets are generated, 
> > one in each direction.
> > In FBD, each time there is an idle period, i packet is generated
>
> Not sure I like either one of these options. Preferrably, the probing 
> frequency
> would depend on whether you have something to send or not. For 
> instance, if
> we don't have any payload packets to send, the frequency = n and if we 
> do have
> packets to send, it would m, m << n. If you combine this with the ULP 
> feedback
> and packet reception in CUD, we have a mechanism that normally does 
> not need
> extra probes during traffic and which generates a very small amount of 
> traffic
> when its idle.

right i am sorry for my really poor wording above (it is just that i 
fail to state the underlaying assumptions)

When i said idle i meant that one end is sending but it is not 
receiving anything, like an unidirectional flow.
So, if we are in a situation of an unidirectional flow, and no ULP 
feedback (which is worse case when considering the amount of probes 
needed) then it results what i pointed above i.e.:

- an endpoint that is sending but not receiving in CUD will result in 
an additional overhead of 2 signaling packets one in each direction 
periodically , while,
- an endpoint that is sending but not receiving in FBD will result in 
an additional overhead of 1 signaling packet in the incoming direction  
periodically

> > - ULP interaction
> >
> > As defined in the draft, CUD requires ULP feedback in order to 
> > greatly reduce overhead. However, as i mentioned above, i think that 
> > a workaround can be used to deal with this issue.
>
> I think we can assume that an optimized Shim6 implementation gets ULP 
> feedback.
> NUD needs it anyway, so its not a big assumption.
>
> > IMHO, both mechanisms can benefit from negative ULP feedback in a 
> > similar way, since CUD wouldn't need to wait for Tu and FBD wouldn't 
> > have to wait for n*t. Probably, the benefit is much greater in FDB.
>
> Yes.
>
> > So, as far as i can see, both mechanisms behave quite similarly. 
> > Probably, the main difference is w.r.t. the overhead, where FBD is 
> > superior.
>
> The mechanisms are very close indeed, particularly if you consider 
> that both
> benefit from some ULP feedback. What you wrote later:
>
> > In this extended CUD scheme there are three elements in the failure 
> > detection:
> > - ULP feedback
> > - incoming traffic
> > - explicit reachability tests
>
> seems to make a lot of sense to me. Does the no-exponential-backoff 
> property
> hold for this too (except for the 3rd item)?

I think so, i only see the exponential backoff in the probing mechanisms

regards, marcelo


> --Jari