Re: GIST Q/D-mode issue

hi,

comments below (mainly at the end). 

short summary: my preference at the moment is to
use the flag bit method, but to put the flag at
the start of the message type field. (saves a bit,
and brings out the relationship between flag and
message type.)

more below ... 

> -----Original Message-----
> From: Roland Bless [mailto:[email protected]] 
> Sent: 11 September 2008 08:38
> To: Hancock, Robert
> Cc: Lauri J T Liuhto; [email protected]
> Subject: Re: [NSIS] 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.

that's quite right - my point was that you should not have had
to use the RAO to work that out.

> 
> > 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/tr
unk/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.

indeed (see also at the end). i think we would have one extra
error, 'invalid Q-flag' causing the message to be dropped.
(I see it as another instance of a formatting error.)

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

there are two points:

- for a NAT, it does the operation on the message based on the
presence of the Q flag only. it doesn't check if that flag was
valid for the message type.

- the end system needs to decide if the Q flag, message type, and
internal state are all consistent. this will require logic changes
if the set of message types changes - but these would be required
at the end system anyway (to cope with a new message).

cheers,

robert h.

> 
> Regards,
>  Roland
> 
>