Subject: Re: [NSIS] GIST: Responding Node D-Mode to C-Mode upgrade?

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 1 Aug 2007 11:46:47 +0300 (EEST)

Hi,

I had a good chat yesterday with Nuutti about this, and we came to the 
conclusion, that point b) would be the simple and right thing to do. Of 
course this creates a rather problematic situation for NSLPs, but other 
solutions would probably lead to complex signaling scenarios.

Can the NSLP query the MTU for the MA? If so, we should just stress in the 
GIST spec, that in case of D-mode the NSLP should ask for and respect the 
MTU, otherwise a local error will be indicated and the message will not be 
delivered.

regards,
Jukka

On Tue, 31 Jul 2007, Roland Bless wrote:

> Hi Robert,
> 
> this is an old topic, but probably still not solved
> satisfactory. Nuutti Varis, who is currently implementing
> GIST at University of Helsinki, came also across this issue
> again.
> 
> Problem: in case a responding node has
> to send a payload larger than the MAX_MTU size, it
> currently cannot upgrade the session from D-Mode
> to C-mode, because it is a responding node.
> See also
> http://www1.ietf.org/mail-archive/web/nsis/current/msg05672.html
> and your answer here:
> http://www1.ietf.org/mail-archive/web/nsis/current/msg05676.html
> Same applies for requiring a reliable transfer mode on the responder
> side when only an unreliable transfer was considered by the querier
> so far.
> 
> I could think of the following alternatives:
> a) the responding node queues the data for transmission and sends
>    and informative error message to the querier who can then decide
>    on upgrading the session to C-mode. This has the problem that we
>    need a timer on the responder side and must wait until the MA
>    is established. Otherwise it will notify the application
>    with a MessageStatus() call that the message could not be sent.
>    Probably a part of the code could be re-used that is already
>    there for initial setup of an MA. Furthermore, even smaller
>    D-mode messages must enqueue behind this earlier message,
>    because in order delivery for the same session is required.
> 
> b) indicate a local error condition
>    via MessageStatus that the message is too large. However, reacting
>    to this failure situation requires probably a similar logic that
>    could have been used by the application itself _before_ calling
>    the SendMessage() call.
> 
> c) see it as global policy for the NSLP as in your answer.
> 
> However, it would be good to mention the problem (and a solution)
> in the draft at least.
> Any other opinions?
> 
> Regards,
>  Roland
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Wed, 01 Aug 2007 13:42:12 +0200

Hi Jukka,

> solutions would probably lead to complex signaling scenarios.

At least it would give the NSLP programmer a hint that he must
think twice before sending things over D-mode.

> Can the NSLP query the MTU for the MA? If so, we should just stress in the 

As far as I know it is fixed (576 bytes) for D-mode (see sec. 4.3.3).
For MAs there is probably no MTU that we need to be aware of (at least
for SCTP and TCP) since reliable MAs will transport messages of an
"arbitrary" size.

> MTU, otherwise a local error will be indicated and the message will not be 

The problem is that, there is no work around in this case.
So if at some point in time the message gets too large, which
can probably not be always be foreseen by the NSLP designer,
the application will basically hang if this situation occurs.
The history is full of system failures due to events that
occurred although they were supposed to never happen (during
the design and test phase)...
So there is no graceful recovery or way out for an application
which is the main thing that I'm concerned about.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 07 Aug 2007 14:43:16 +0200

Hi Robert,

> to C-mode, because it is a responding node.

Just as an add-on:
The same is true for upgrading from unsecure to
secure mode.

Regards,
 Roland