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