Re: GIST Q/D-mode issue

Hi Lauri,

good that you are coming back on this issue, since I was also
a little bit confused by the proposal to use a new port for the
issue.

Lauri J T Liuhto wrote:
>  First a very short summary of the Q/D-mode issue of NTLPv16 Nuutti
>  Varis found in July:
> 
>         It seems that it is impossible to differentiate Q-mode and
>         D-mode Data messages in a middlebox if Data message is sent
>         with GIST Common Header S-flag set.
>  
>  A more detailed example of this issue is attached to the end of this
>  message.
> 
>  The issue was briefly discussed at Dublin, and it seems that we have
>  at least two different solutions to the issue:
> 
>  1) Add a "Q" flag to the GIST Common Header, that would be set
>     whenever the message is a Q-mode message.
>     + Closely resembles RAO in UDP payload
>     + Should be easy to fit in the spec
      + does not use another different well-known port number
>     - Existing implementations need changes
>     - If done, only four free bits remain in GCH

>  2) Use different port for D-mode messages.
>     + Scarce GCH flag reserve not used
>     - Bigger changes to spec
>     - Possible NAT/Firewall issues
>     - Existing implementations need more complex changes
      - requires using a different well-known port number

As an implementer I'm much in favor of solution 1):
requires only a few code changes and produces less error
cases, since in the using a different port case other
messages may arrive on the new port as well etc.
Listening on two different ports simultaneously for messages
also requires more system resources and probably major code changes
compared to 1).

I'd like to propose a different option 3): why not use a new message
type for stateless DATA messages? From the internal protocol logic
this would also be easy to implement as a Q-flag, since this type
of DATA message needs a special handling, but it avoids
wasting the flag bit.

Regards,
 Roland