Subject: [NSIS] Stack Proposal Profiles: ordering of protocol numbers?

From: Thomas Herzog <[email-masked]>
Date: Sat, 01 Oct 2005 16:28:11 +0200

Hi,

I am currently in the process of implementing the message association 
setup for GIST, so I must validate Stack Profiles against each other. 
The format of the Profiles is defined as a list of Protocol IDs, and 
there are some Profiles defined in the draft (TCP, TLS/TCP, TLS/SCTP), 
but however the "ordering" of the Protocols is not defined.

So TLS/TCP could be laid out on bitlevel format like (2,56,6), but also 
(2,6,56). (2 being the length of the profile field).

This may not be a problem if we only use the predefined profiles which 
currently only employ 2 protocol layers, but if there will be profiles 
in the future using 3 or more layers, checking for validity would become 
even more complex.

So my question: Wouldn't it be good, if one defined the ordering of the 
protocols in a profile explicitly as "use Protocol #1 over Protocol #2 
over ... Protocol #n"?

So if one needs to validate profiles against each other, one could 
simply stop if the first (and such topmost) Protocol ID differs/is not 
supported?

Cheers, Thomas

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

---

From: [email-masked]
Date: Mon, 3 Oct 2005 14:21:23 +0100

Hi, Robert,

Thank you for your reply, Please see my comments below. 

Quoting "Hancock, Robert" <[email-masked]>:

> Hi Jia Jia,
> 
> You raise a valid question about 'refresh' handling.
> Essentially I think there is a design choice which could
> go two ways:
> a) handle refresh messages differently (no need for retransmission,
> just assume that a refresh will get through before routing state
> expires), or
> b) handle all Query messages the same way (retransmission with
> an exponential backoff).
> 
> The design choice in GIST is (b). This isn't explicit in 5.3.3
> but is (I hope) in 6.2, which is supposed to capture this sort
> of detail more precisely. 
> 
> So, one question would be whether this needs to be explained
> better.

Section 6.2 of GIST does illustrate the design choice (b) better. However,
I still think that it needs to be explained more clearly and in more details.
For instance, The query node state machine in Fig.6 (section 6.2) indicates
that,when the query node is at the "Awaiting Refresh" state and receives a
ResponseMessage, it still needs to check whether a Confirm is required and send
the Confirm if required. I think maybe it could be better if this information
is also mentioned at Section 4.4.3 "State Maintenance Procedures"?

Moreover, I didn't find the clear information about how a query node can
determine whether a Confirm is required or not in the draft although the GIST
draft did imply that the query node can determine that based on the R flag of
the Common Header of the received Response message.  

> The other question would be whether the design decision is
> correct in the first place. Given that we have a retransmission
> mechanism for the initial Query, I think it is simpler to use
> it for the refresh case also. Otherwise, there is a more 
> complex analysis needed for the timer setting for sending
> refresh messages to account for the fact that one may be lost;
> it also becomes trickier thinking about the fact that the
> RS-validity time can be changed by either end.

I understand the design decision of treating all the query messages in the same
way to eliminate the complex analysis. I notice in Fig. 6 of section 6.2 that 
the "Awaiting Response" state and the "Awaiting Refresh" state use the same rule
for their retransmission. Does it mean that the "Awaiting Refresh" state will
set the same T1 and T2 timeout values (for retransmission algorithm) as the
"Awaiting Response" state does, without considering the Validality Time of both
nodes at all? 

In addition, when a NSLP needs the GIST to send one NSLP message, it indicates a
Timeout value to the GIST, which specifies the length of time GIST should
attempt to send this message before indicating an error. Then, My question is:
what is the relationship between the T2 timeout value of the retransmission
algorithm and this NSLP Timeout value? 

Fig. 6 of section 6.2 shows that, if the number of Queries sent has reached the
threshold and no Response message is received, the GIST will indicate NO
Response error to NSLP. 
However, as mentioned before, when the NSLP Timeout value is reached and the
NSLP data was not sent out, the GIST should indicate an error to the NSLP. Is
there any better way to relate the T2 value with the NSLP Timeout value and
then to report only one error to the NSLP instead of two?
 
> (So, a third question would be whether more of this rationale
> should be captured.)
 
 Cheers,
 
 Jia Jia

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > Sent: 29 September 2005 11:28
> > To: Hancock, Robert
> > Cc: [email-masked]
> > Subject: [NSIS]about retransmission of fresh query messages
> > 
> > 
> > Hi, Robert,
> > 
> > Thanks for your prompt reply. I have another question to ask.
> > 
> > In section 5.3.3, the draft describes the retransmission algorithms
> > against the losses of Query, Response and Confirm messages. However, 
> > It seems that the draft doesn't specify when the 
> > retransmission algorithms 
> > should be used (correct me if I am wrong).
> > I know the retransmission algorithms should be used in the case that
> > the Q-node needs to discover its downstream peer by sending a 
> > new Query
> > message.
> > My question is that:
> > 
> > should the retransmission algorithms also be used against the loss of
> > refresh Query message? As we know, sending refresh Query 
> > message involves 
> > validality times of both Q-node and R-node. Then, how should 
> > the T1 and T2 
> > timeout values (see section 5.3.3) be chosen in the case of 
> > retransmitting
> > refresh 
> > Query message? 
> > 
> > My opinion is that we don't need to re-send any refresh Query 
> > message and just
> > let 
> > the routing state removed if any refresh Query/response 
> > message is lost on the
> > way.
> > And then, the Q-node can have a new handshake process if it 
> > needs to send any
> > message to
> > its downstream peer afterwards. Any comments are welcome.
> > 
> > Cheers,
> > 
> > jia jia
> > 
> > Quoting "Hancock, Robert" <[email-masked]>:
> > 
> > > Hi Jia Jia,
> > > 
> > > the crucial phrase in the NTLP spec is in section 4.3:
> > > 
> > >   "It is the responsibility of the Querying node to generate
> > >    a GIMPS-Query message before this timer expires, if it 
> > believes that
> > >    the flow is still active; otherwise, the Responding node 
> > may delete
> > >    the state."
> > > 
> > > In other words, it's intended to be up to the implementor; the -08
> > > version will say this in slightly more formal terms in the state
> > > machines description (section 6.2). Your formula seems quite
> > > reasonable to me; a more cautious implementor might also include
> > > some jitter to avoid network synchronisation problems.
> > > 
> > > It would be a good wg last call point to discuss exactly how 
> > > prescriptive the specification should be on this sort of issue.
> > > 
> > > cheers,
> > > 
> > > robert h.
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]] On 
> > > > Behalf Of [email-masked]
> > > > Sent: 26 September 2005 15:14
> > > > To: [email-masked]
> > > > Subject: [NSIS] about refresh query
> > > > 
> > > > 
> > > > 
> > > > Dear colleagues, I am implementing the background maintenance 
> > > > support for GIST
> > > > now, which needs to send  refresh Query Messages after the 
> > > > Routing State is
> > > > installed at the Q-node. The NTLP draft specifies the 
> > > > validality time in the
> > > > NLI object, which means that the Query-node or Response-node 
> > > > will remove the
> > > > Routing State from its routing table if this node doesn't 
> > > > receive any refresh
> > > > Query/Response messages during the validality time period. My 
> > > > question is that:
> > > > 
> > > > 
> > > > What is the timeout value I should set for the Timer of 
> > > > sending the refresh
> > > > Query message? Obviously, it is not appropriate that the 
> > > > timeout value is set
> > > > to the validality time and it seems that the ntlp draft 
> > > > doesn't notice this
> > > > issue. Now I set the timeout for the Timer of sending refresh 
> > > > query message as
> > > > follows: timeout = min(ValidalityTime of Q-node, ValidalityTime of
> > > > R-node)*fraction_factor, ( fraction_factor= 3/4, currently). 
> > > > Any comments are
> > > > welcome.
> > > > 
> > > > Best Regards
> > > > 
> > > > Jia Jia
> > > >