ASAP Draft
Goyal Anurag-A20942 <[email protected]> Tue, 11 Jan 2005 00:26:26 +0530
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
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