Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect?

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 8 Feb 2006 12:17:01 +0100

Hi Roland,

thanks for your analyisis and your proposal. The timer is 
required indeed and I'm happy to go with your suggestion 
on the timer value and simple repeat mechanism.

|My conclusion:
|- We probably need the ACK only when GIST is used in an
|  unreliable transport mode, otherwise it's not required.

If GIST is able to detect a broken reliable transport connection 
by its own (i.e. GIST functionalities), I agree. I recall a 
bad TCP implementation below MPLS LDP some years ago. LDP had no 
facilities to detect this. The result was service disruption 
without possibility to recognise the event or the location 
where it happened. NSLP/GIST should not repeat this design error.

If GIST is not able to detect a broken reliable transport mechanism 
by a GIST mechanism, I'd like to propose the ACK also in reliable 
transport mode.

|- We must determine some timeout value. I would
|  suggest to set it to 0.5s, 1s and 1.5s by default, i.e.
|  at most 3 retransmissions. Retransmitting the RESERVE would
|  do no harm because the next QNE can use the RSN to check
|  for duplicates.

Regards,

Rüdiger

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 Feb 2006 14:29:39 +0100

Hi Ruediger,

> on the timer value and simple repeat mechanism.

Currently, I have the impression that we have specified a solution for
a problem that isn't clearly defined. Therefore it would be helpful
to clearly describe the problem that the ACK mechanism is intended to
solve. Then we are probably better in designing a minimal mechanism that
actually solves the particular problem and prevent to design a
rather generic ACK scheme for a set of (nonrelevant) problems.

> by a GIST mechanism, I'd like to propose the ACK also in reliable 

There is the MA-Hello mechanism in GIST which also allows to detect
a failed messaging association (though this is not the main intention
of MA Hellos, right?). The MA-Hold-Time is indicated
to a peer during the setup phase. Thus, one is basically able to react
faster than TCP would detect a dead peer if the NoHello Timeout is small
enough.

> |  do no harm because the next QNE can use the RSN to check

Regards,
 Roland