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

From: Roland Bless <[email-masked]>
Date: Fri, 10 Mar 2006 17:54:45 +0100

Hi,

[sorry, but I guess that I have still some major issues
with the ACK]

Jukka MJ Manner wrote:
> No objections here.

I'm really sorry, but I was thinking again about this ACK mechanism,
because I'm not really convinced of its usefulness in general.
It will mean _a lot_ of overhead. When reading the motivation
(which was added later on my request) in section 3.2.4.:
"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." (BTW this doesn't fit exactly to the section topic
"Explicit state installation confirmation and responses").
The described goal could be achieved with less overhead
by using a heartbeat mechanism per peer
rather than requiring an ACK for each RESERVE (per flow). Sure, the
latter contains also more information, because it is a confirmation of
state installation action, but I'm not really sure that we need it all,
because it is of limited use anyway compared to the RESPONSE triggered
by an RII object.

The only two potential other reasons in the current
draft may be:
- use of unreliable GIST transport (in this case we obviously
  don't care about the RESERVE's fate and should not
  try to add reliability, otherwise we better request a
  reliable transport from GIST)
  => no reason
- for acknowledgment of reduced refreshes (as indicated in
  section 3.2.5):
  "These reduced
   refreshes require an explicit acknowledgment of state installation to
   ensure that the RSN reference will be understood. It is up to a QNE
   that receives a message containing an RII to decide whether it wants
   to accept reduced refreshes and provide this explicit acknowledgment."

  Besides the fact that I don't understand the last sentence I also
  don't know why reduced refreshes require an ACK and what means:
  "that the RSN reference will be understood".
  -> in case the reservation is unknown we'll get a RESPONSE
  back with "full QSPEC required", no ACK required
  -> in case the RSN is somehow out of sync (how should this
  happen, and, this could also be the case for normal, not reduced
  refreshes, so it is not specific to reduced refreshes) we
  may have a problem. Suppose a node sends a refresh with a smaller
  RSN than expected then it will be ignored and the state at the
  next node will timeout after a while. In case the RSN is higher
  than expected, the node will also emit a RESPONSE with full QSPEC
  required. So I don't see the usefulness of the proposed ACK.

Consequently I would prefer removal of the ACK flag and possibly
provide a simple HELLO mechanism (with adjustable timeouts)
between peers to detect communication failures. I really don't know
what fast reaction an application could undertake due a
transmission/processing failure of a RESERVE message that was
detected by the currently proposed ACK mechanism. -> see below

>>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
                                            ^^^^^^^^^^^^^^^
better: (defaults to QOSNSLP_REQUEST_RETRY, see below)

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

Nevertheless an incoming retransmission by the RII inserting node
could happen well before QOSNSLP_ACK_WAIT_MAX and should stop
therefore stop any local retransmissions.

>>   RESERVE, a failure should be indicated to the signaling
>>   application.

Is this enough? Shouldn't the application send a NOTIFY upstream
indicating a transport failure? What can the application do about
it? Possibly a rerouting will happen in case there are alternatives,
but if there aren't any we have a longer-term problem anyway.

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

Retransmissions as proposed in the latter paragraph should
be kept though.

Regards,
 Roland

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 20 Mar 2006 08:39:06 +0100

Hi Roland,

Jukka's intentions on Ack's at the access aren't too far from mine. 
My personal preferenceis to operate NSIS on customer network edges only. 
I'd expect no more than 4 QoS NSLP speaking devices along a path. 
Any Reserve passing a customer edge should be Acked anyway, 
I think (similar as Jukka). 

I didn't read the draft how to couple RSVP to Bob Briscoe's 

http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-01.pdf .

But I'm pretty sure that the destination edge router informs the 
upstream origin edge router about the congestion state of the backbone. 
In the case of QoS NSLP, that doesn't need to be an Ack, but if the 
Ack was there anyway, it could nicely be used.

That's a little bit more than a bare keep alive mechanism now. It is 
a special case too, as others will prefer other QoS NSLP architectures. 

Regards,

Rüdiger

|You are right. I would prefer to always get a RESPONSE (from the QNR
|or far end).
|The ACK mechanism is a different thing, because it is only triggering
|a response from the direct peer. It would help a lot if we could
|actually write down the requirements. From the past discussions I
|have the impression that people want to achieve totally 
|different things with the defined retransmission mechanisms. 
|Thus it would be good to clearly describe the problem(s) we want 
|to solve. Short summary:
|Ruediger: wants liveliness check
|Georgious: wants some confirmation (for what purpose?)
|Jukka: wants to recover loss(?) in case of unreliable
|transport (wants to avoid using TCP for mobile nodes...)