Re: GIST Q/D-mode issue

Hi Robert,

thanks for elaborating this. Some more comments below.

Hancock, Robert wrote:
> - at the conceptual level, i think we should distinguish 
> between (a) whether a message is sent in Q- or D-mode, and
> (b) whether a message has to be interpreted when received 
> in the absence of routing state. in the current spec, either
> of these classify messages the same way, but the concepts 
> are distinct: (a) is about sender behaviour [mainly, formatting
> the message to follow a data path] and (b) is about
> receiver behaviour [knowing how to decode what you get].

That's exactly true, nice and clear distinction that I had
in mind, but I wasn't able to express it so clearly :-)
For Q-mode Data messages the concepts were a little bit
intermingled since a Data message had to be interpreted differently
if received in Q-mode (as you describe below, too).

> The overall issue comes up in the NAT traversal case, and
> the point (I think) is that the NAT has to do special 
> special processing for messages received without prior
> routing state.

Ok.

> - this actually exposes a flaw in the previous spec: it was
> never supposed to matter to a receiver whether a message
> was received in Q- or D-mode, it only mattered to the
> sender. (The receiver only cared about the message type.)

> The fact that it was possible to tell the difference from
> the presence of the RAO was a design artifact (the RAO was
> supposed to assist message interception, not change the
> semantics of the message.)

Yes, however, if a message came with an RAO, it came via Q-mode
encapsulation and that was what mattered for our case distinction.

> Taking into account the conceptual distinctions above, it
> is still the case that it shouldn't matter to the 
> receiver whether a message was in Q- or D-mode, but it does
> matter whether routing state is supposed to be used in
> interpreting it.

If I look at our source code we first check whether
a corresponding routing state exists and then check
for the message type. If the Data message came via Q-mode,
we deliver it, if it did not arrive via Q-mode
we have an error condition (e.g, because a Confirm
was lost):
https://projekte.tm.uni-karlsruhe.de/trac/NSIS/browser/ntlp/trunk/src/ntlp_statemodule_main.cpp#L703
So Q-mode/D-mode distinction is in this case important
to decide whether the Data message has to be interpreted although
no routing state exists. That could also be achieved by the
different message type that I proposed, but I agree with your
counter argument below.

> this is half attractive for saving the flag bit. however, there is
> an issue about extensibility: what if later on another message type
> turns up which also needs to be processed by the NAT in the same
> way - the NAT implementations need to have a list of message
> types to care about, and that list might extend. 

Ok, good point. In that case it is a good reason to do it differently.

> but there's another way of saying the same thing: divide the message
> types into two classes, those to be intercepted by NATs and those
> which are not. distinguish them by the high-bit in the message 
> type field. (it reduces the number of distinct message types from
> 256 to 128, but that seems not impossible.) obviously, this is the
> same as just putting the hypothetical Q-flag in a different place
> in the header (and calling it something else.)

Yep. I think it is useful to have an explicit indication for
your function (a), i.e., a Q-mode flag in the message, however,
formerly whether a GIST message arrived via Q-mode or D-mode
was not visible in the GIST message itself, only by the outer
encapsulation method. Having a Q-mode flag would now generate
new error conditions to check for, e.g, if Q-mode flag is set
in a C-mode message etc.

> in another mail:
> 
>> Max Laier proposed option 4):
>> use a different magic number for Q-Mode and D-Mode messages.
>> Any opinions?
> 
> i don't really like this. i have generated the appropriate
> random number (4d62 8fa0), but it still seems like a hack.
> and the same issues about extensibility apply.
> 
> when i first analysed this problem, i couldn't find a better
> solution than the Q-flag or something like it: in other words,
> you have to change the message formats. within the design
> space of format changes, my favourite is still option (1), or
> modified option (3) if flag bit space exhaustion seems like
> a problem.

Agreed. The question is, whether there are cases in which
the message does not arrive via Q-mode, but the message has
to be interpreted nevertheless in case of missing routing state.
So this would be a flag exactly for your function (b) from above,
something like a stateLess flag
"if this message arrived and no routing state exists,
it is ok to interpret it nevertheless". However, since this is
allowed for certain message types only we have to check the
particular message type, too. So it is not clear to me, whether
we could actually avoid the above mentioned list of message types
that NATs have to care about.

Regards,
 Roland