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

From: Roland Bless <[email-masked]>
Date: Thu, 02 Feb 2006 23:08:33 +0100

Hi,

a quick question: Currently, a RESERVE with an ACK flag
will trigger an immediate RESPONSE, but...
this will have no effect on the state machine, e.g.
no timer is started, no retransmission triggered if the
response is missing etc.
Therefore the provisional RESPONSE triggered by the
ACK flag will have no effect, so currently it is pretty
useless?!

Furthermore, the RESPONSE codes for the ACK triggered responses
are inconsistent:

   If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state
   installation action. It does so by sending a RESPONSE with an
   INFO_SPEC indicating that the reservation is installed at the QNE
   (code 0x03).

   ...

 5.4.3.  RESPONSE Messages
   ...

   In this case a successful RESPONSE carries
   the INFO_SPEC with success code 0x01 and the received message is
   forwarded further along the path towards the QNR.

Regards,
 Roland

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Feb 2006 10:22:35 +0100

Hi Roland

Your observations are right!
Could you please propose the text that solves these problems!

Best Regards,
Georgios

----- Original Message ----- 
From: "Roland Bless" <[email-masked]>
To: "nsis" <[email-masked]>; "Andrew McDonald" <[email-masked]>; 
"Jukka MJ Manner" <[email-masked]>; "Georgios Karagiannis" 
<[email-masked]>
Sent: Thursday, February 02, 2006 11:08 PM
Subject: QoS NSLP: ACK flag has no effect?

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 Feb 2006 11:44:51 +0100

Hi Georgios,
> Could you please propose the text that solves these problems!

I can try to send text, but I'm not really sure about
the purpose of this ACK mechanism. I guess Ruediger
Geib wanted it (that's why I put him into the CC).
Maybe he can shed some light on it.

My observations so far:
- the ACK flag is currently set by default.
  I'm not sure whether this is _really_ required
  if we have a GIST reliable transport below QoS NSLP.
  So similar to SIP we could make it default in case
  of unreliable transport, but otherwise it's not used.
  It will only have a benefit in case that a notification
  of a broken connection by GIST takes a long time, e.g.
  until TCP reports connections failure.
- If ACK should have any effect, we probably want to
  retransmit the RESERVE after a very short time
  if the RESPONSE is missing. However, we have a lot
  of options:
  * How long should we make the (default) timeout?
  * 200ms, 500ms? (it's only the "next" hop)
  * Exponential backoff? How many retries?
  * Should we signal the expected reply period to the peer?
  * The timeout could be made adaptive so that we measure
    the average time until an ACK usually arrives.
- In case something will go wrong (state installation did
  not succeed), a negative RESPONSE is sent back immediately
  anyway.
- In sec. 3.2.5 it is mentioned that reduced refreshes
  require an ACK "to ensure that the RSN will be understood".
  However, in case we have reliable transport
  and the RSN is not understood, we get a response indicating
  the problem anyway.

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

>>   forwarded further along the path towards the QNR.

I would suggest to use code 0x01 in both cases. However, 0x01 has
the actual meaning of
"State installation/refresh/modification succeeded"

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 8 Feb 2006 13:18:50 +0200 (EET)

Hi,

Sounds good to me. 

Retransmissions are traditionally exponential and not very agressive to
not cause DoS attacks, so if we start with 500ms, then the next will
happen after 1000ms, then 2000ms, and so on if more than three are sent.
Also, some random parameter in the retransmission helps to protect from
network synchronization.

GIST leaves the retransmission parameters to implementations, though.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 Feb 2006 13:41:54 +0100

Hi Jukka,
> Sounds good to me. 

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 describe the problem that the ACK mechanism is intended to solve.

> happen after 1000ms, then 2000ms, and so on if more than three are sent.

Sure, I know that. However, maybe we have also a retransmission from
end-to-end when an RII is given, so the retransmission
between two hops should be faster than the end-to-end retransmission.
That's why I did not strictly follow the exponential backoff scheme.
However, if we decide to actually measure the "RTT" then we should
use an exponential backoff scheme, but we need some extra state for the
estimated RTT and I'm not sure whether we really need the additional
complexity.

> Also, some random parameter in the retransmission helps to protect from

Yep. so the above mentioned values are upper bounds or average values...

> GIST leaves the retransmission parameters to implementations, though.

I'm not sure whether we should do it the same way...

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 21 Feb 2006 00:06:55 +0100

Hi Georgios, Andrew, Jukka,

> Could you please propose the text that solves these problems!

Ok, after some discussion with Ruediger, now my proposal.
--------
3.2.4.  Explicit state installation confirmation and responses

   A QoS NSLP instance MAY request an explicit confirmation of its state
   installation actions from the immediate upstream or downstream peer.
   This is achieved by using an ACKNOWLEDGE (A) flag in the message
   header.
--------
ADD:
   This mechanism enables a QoS NSLP instance to rapidly detect a
   failure of the peer QoS NSLP instance or the underlying transport,
   i.e., either GIST itself or the used transport protocol below,
   e.g. TCP.
--------
5.2.4.  Retransmissions

   QoS-NSLP messages for which a response is requested but fail to
   elicit a response are retransmitted. The initial retransmission
   occurs after a QOSNSLP_REQUEST_RETRY wait period. Retransmissions
   MUST be made with exponentially increasing wait intervals (doubling
   the wait each time).  QoS-NSLP messages should be retransmitted until
   either a response (which might be an error) has been obtained, or
   until QOSNSLP_RETRY_MAX seconds after the initial transmission.
-------
REPLACE:
5.2.4.  Retransmissions

   There are two retransmission mechanisms for RESERVE, one for
   retransmissions between two directly adjacent QNEs (using the ACK
   flag), and one for end-to-end retransmissions, e.g., between
   QNI and QNR (using an RII object).

   First, in case a QNE transmits a RESERVE with a set ACK flag it
   awaits a RESPONSE (either positive or an error) from the receiving
   QNE as acknowledgment of processing the REQUEST. If there is no such
   acknowledgment, the sender may resend the same message after a
   timeout of QOSNSLP_ACK_WAIT with an initial value of 500 ms.
   The timeout may be dynamically determined like the RTO for TCP
   in rules 2.2 and 2.3 from [RFC 2988]. An implementation MAY cache
   the last RTO measurement as the initial value for future requests
   to the QNE. Further retransmissions may be initiated with
   exponentially increasing wait intervals (doubling the wait interval
   each time) up to QOSNSLP_ACK_WAIT_MAX (defaults to 2s) after
   the initial transmission. The latter limit is provided to ensure
   a fast reaction to failures and to avoid conflicts with a potential
   retransmission when an included RII object will trigger another
   retransmission. In case no RII object is contained in the
   RESERVE, a failure should be indicated to the signaling
   application.

   Second, in case a QNE transmits a RESERVE with an RII object set it
   waits for a RESPONSE from the responding QNE.
   QoS-NSLP messages for which a response is requested by including
   an RII object, but fail to elicit a response are retransmitted.
   The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY
   wait period. Retransmissions MUST be made with exponentially
   increasing wait intervals (doubling the wait each time). QoS-NSLP
   messages should be retransmitted until either a response (which might
   be an error) has been obtained, or until QOSNSLP_RETRY_MAX seconds
   after the initial transmission. In the latter case, a failure should
   be indicated to the signaling application.
---------

Any objections?
 Roland

> Best Regards,
> Georgios
> 
> ----- Original Message ----- From: "Roland Bless" <[email-masked]>
> To: "nsis" <[email-masked]>; "Andrew McDonald"
> <[email-masked]>; "Jukka MJ Manner"
> <[email-masked]>; "Georgios Karagiannis" <[email-masked]>

-- 
Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless
Institut für Telematik, Universität Karlsruhe (TH), Germany
Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358
Tel.: +49 721 608-6413 Fax: +49 721 608-6789

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 21 Feb 2006 19:54:22 +0200 (EET)

Hi,
No objections here.

Jukka