Re: new version of the reachability & exploration protocol

[Jari Arkko <jari.arkko@piuha.net>]

Iljitsch van Beijnum wrote:

> In your fourth example the first communication from B to A is to  
> complain that B doesn't receive any data. That's not really  
> possible... If B has nothing else to send, and it doesn't receive  
> anything, it will just assume the 

The example flow may need some explanation. At the point that the first
complaint is sent, B has been sending packets but is not hearing anything;
this is against the FBD rule so it kicks on a check/exploration.

> link is idle. But A is sending and  doesn't receive anything, so in 
> this case A will start the  reachability exploration at some point on 
> its own.

Yes. But that's not the case that this example tries to show; it tries to
show a situation where B->A gets through but A->B doesn't.

> I'm not sure an explicity "I see you" flag is necessary, but maybe it  
> just functions as a "reply requested" flag...

Well, I looked at your document today for five minutes, so I
can't really say if it matches your reply requested flag. However,
in this protocol the "I see you" flag is used to initiate an
exploration at the other side. Remember that this protocol
is designed to do both reachability and exploration at the
same time. So, for the regular FBD fillers in an unidirectional
case we simply set "I see you" = true, and the peer knows that
we are happing, simply letting him know that we see him
even if we have nothing to send ourselves.

If, on the other hand, we do not see any packets but we believe
we should be seeing them, then the flag is set to false. At that
point the peer knows that it needs to explore on its side to find
a working path to us.

When this finally is found, we see a packet and set the flag to
true in subsequent messages. Finally the peer sees this and
stops his exploration.

> I find the state diagram confusing: many of the states are non- 
> obvious. I think it would be better to have a separate per-context  
> state diagram along with another state diagram for the reachability  
> testing. (Although in this draft you do not differentiate between per- 
> context and host-wide behavior.)

The draft did not yet take a stand on the exploration being per host or
per context. Did we reach a decision on this yet?

Regarding the state diagram, you'll be even more confused when you
find out some of the things it doesn't yet do.

And its complex.

Having said this, attempting to construct the diagram has been
extremely educational. Its easy to throw a design on a slide
or draft with example flows. But making the protocol operation
waterproof in all scenarios is, ah, challenging.

So, I'm painfully aware that the diagram is hard to understand
and has even some real-life issues. However, whatever we do,
I'd really like to see us understand the small details, and the
behaviour of the protocol under different situations. If you
and I can't specify what the protocol is supposed to do in
different circumstances, will the implementers able to?

> It's amusing to see that the protocols each of us came up with are  
> almost 100% different.

:-) But lets see what the real differences are. I want to understand
what your protocol does in order to determine whether the differences
are in presentation or behaviour. From first look, I didn't actually
see so many fundamental differences... the main difference appears
to be formats, and that I wanted to handle both reachability and
exploration with the same protocol.

> BTW, my last name is "Van Beijnum" (capitalization of the V changes  
> depending on the presence of a first name or initials).

Sorry. Hmm... not sure how to fix this in xml2rfc. I'll figure out
it somehow.

--Jari