Re: CUD and FBD

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 7-okt-2005, at 10:28, marcelo bagnulo braun wrote:

> > > 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.

In CUD, if we have nothing to send we don't probe either.

In FBD, the situation where we have nothing to send (but we do  
receive packets from the other end) is exactly the situation where we  
need to send keepalives to let the other side know we're still there.

> > 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.

Both FBD and CUD are quiet when the session is idle in both directions.

> - 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

Right.

> > I think we can assume that an optimized Shim6 implementation gets  
> > ULP feedback.
> > NUD needs it anyway, so its not a big assumption.

Maybe there will be some sort of feedback, but I'm not convinced it  
will help us all that much. AFAIK, NUD results in a significant  
number of additional neighbor solicitations.

However, I want to reiterate something I talked about earlier:

Rather than choose CUD or FBD and expect vendors to implement this  
correctly, we can define the probing such that it gives implementers  
maximum flexibility. This has the advantage that we don't have to  
spend large amounts of brainpower coming up with the perfect solution  
before there is operational experience, and that implementers can  
begin with something simple and extend it later.

The idea is that we basically specify CUD as the basic approach. So  
first of all, when there is no outgoing traffic, nothing happens.  
Also, in the presence of positive ULP feedback nothing happens. When  
there is outgoing traffic but no positive feedback, the shim layer  
periodically sends out a probe. The other end sends back a reply when  
it sees the probe.

So far so good.

But in order to optimize for the situation where there is no ULP  
feedback and to reduce the number of probes, a host may indicate that  
it supports two additional capabilities in the probe:

1. That if the other end sees our traffic, it may send a "probe  
reply" without having received a probe first at X second intervals  
for Y probes or seconds.

2. That if the other end sent any other type of packet in the last Z  
seconds, it may suppress the probe reply.

If both ends support both these options this effectively means  
they'll switch to FBD for some time. (Timeout is probably a good idea  
to keep broken implementations from sending unsolicited probes for  
all eternity.) However, if one end doesn't support one or both of the  
additional capabilities nothing happens and we're still at CUD.

So basically this is CUD with the option of moving to FBD later. This  
makes sense unless we can be more or less absolutely certain we  
either never need to move to FBD, or that FBD is at least as good and  
probably better than CUD. Without having done any IP stack  
programming I believe that CUD (possibly with fairly limited ULP  
advice) is easier to implement while FBD is probably more efficient.

I assume we can arrive at a decision on this after some discussion  
this weekend.