[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new version of the reachability & exploration protocol
On 24-okt-2005, at 18:51, Jari Arkko 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
Ah yes, but the diagram doesn't show that...
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.
It's not the same, but I think when all is said and done both flags
pretty much accomplish the same thing, be it in different ways.
However,
in this protocol the "I see you" flag is used to initiate an
exploration at the other side.
This isn't explicit in my draft. (I didn't have time to address less
important details such as this one.)
Remember that this protocol
is designed to do both reachability and exploration at the
same time.
I think it makes more sense to have different message types for this,
as the FBD keepalives will be relatively frequent but full
exploration hopefully much less frequent. Note though that I start a
full exploration after just missing one keepalive.
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?
Would you seriously consider doing a reachability exploration for
each shim context between two hosts when there is more than one shim
context?
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.
Sure, a state diagram or two can be helpful, but I found the states
that are in this one strange. Maybe these are the states that are
required but I don't realize it yet, but it's also possible that
organizing this differently makes everything clearer.
In general, it's a good idea to make two things that can do half the
job independently rather than one big monolithic thing that does the
whole job.
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.
Well, the part that I wrote extensively about is very short in your
draft so it's hard for me to judge whether that part would be very
different.
The most important difference that I see is that in my draft there is
per-context work and per-host work, while in your draft everything is
per-context.
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.
I'll be interested to see if my draft is accepted, as it doesn't have
any page breaks. It's annoying to make this silly layout by hand, but
the xml stuff is worse.