RE: ASAP Draft

The email below highlights an important point regarding the ASAP draft. 

 

Should the T1-ENRPrequest be made generic for all request messages (e.g. registration, deregistration, name resolution) or should specific timers for each procedure be defined? It is unclear in the current ASAP draft v10 since both instances are illustrated as mentioned in the email below. The only use specifically mentioned of the T1-ENRPrequest timer in the ASAP draft is in the name resolution procedure so this timer could be renamed T1-nameresolution. Or the T1-ENRPrequest timer could also be used as a generic timer in the registration and deregistration procedures replacing the T2-registration and the T3-deregistration timers.

 

My opinion is to rename the T1-ENRPrequest timer to the T1-nameresolution timer since I don't see any other use cases/procedures for its use within the draft mentioned. But this assertion obviously can be debated (and I could be completely wrong) and I welcome the insight of RSerPool group members. I would simply like to see some consistency and gain an understanding the groups' view of the use of the timers within the ASAP draft.

 

If we rename the T1 timer or not, I see some subtle points that also need to be addressed as follows:

 

1)       Section 3.7 (Handle ASAP to ENRP Communication Failures)  - bullet B) should be changed from "B) T1-ENRPrequest timer expiration" to "B) ASAP endpoint request message timer expiration" since we have the T2-registration and T3-deregistration timers that can also signal a communication failure and can be a single bullet item. Other options also exist so suggestions are welcome.

2)       Section 3.7.2 (T1-ENRPrequest Timer Expiration) - This section could be eliminated the T1 timer is renamed. If the T1 timer is not renamed we still need to address the parallel nature of sending subsequent message tries and searching for a new home ENRP registrar as described "When a T1-ENRPrequest timer expires, the ASAP should re-send the original request to the ENRP server and re-start the T1-ENRPrequest timer.  In parallel, a SERVER_HUNT message should be issued per Section 3.6." Is this behavior wanted? Re-sending the original message is not described within the registration or deregistration procedures upon T2 or T3 timer expiration. So what does the RSerPool group want the behavior to be in order to consistent in use of response to timer failures? I would lobby for elimination of re-sending the original request.

 

Thanks

Walter 

 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Goyal Anurag-A20942
Sent: Monday, January 10, 2005 12:56 PM
To: [email protected]
Subject: [Rserpool] ASAP Draft

 

Currently the ASAP draft has different timers with distinct timeout values between ASAP endpoints. All operations, like registration, deregistration, name resolution have unique timers  T2-registration, T3-deregistration, and T1-ENRPrequest associated with them. 

 

There are two ways one could go in deciding the timeout value of timers:

(a) Based on network latency only- how sooner do we expect a response from the Registrar (based on communication overhead only) ? 

If this is indeed the case, then we may do away with seperate timeout values for T2-registration, T3-deregistration, and T1-ENRPrequest. In fact, we can even do away with different names for timers for reg/dereg/name resolution and use a generic timer (say T1-EnrpRequest or some other name), with a timeout value based on network latency. 

 

(b) Other way would be to include processing overhead at the Registrar end in addition to the network latency. On receipt of a communication from a PU/PE, the registrar needs to do a set of activities (processing) before responding. Take for example Name Resolution, on receipt of NameResolution Message from a PU/PE, a Registrar needs to do a search for the Name being queried for before responding. Similarly for Registration and Deregistration, Registrar may need to update/search, before responding. Then it makes sense to have different timers for different activities (like we have now). 

 

If we decide to go with this, then we would be better off renaming T1-ENRPrequest as T1-NameResolution. This would make the name correspond to the activity PU is undertaking at this point of time. Also, this would bring it in sync with the naming convention for registration/deregistration timers.

 

Thanks,

Anurag

_______________________________________________
rserpool mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rserpool