> > >>> Implementations MUST limit the rate of performing this test. The PaC >>> and the PAA can handle rate limitation on their own, they do not have >>> to perform any coordination with each other. There is no negotiation >>> of timers for this purpose. Additionally, an implementation MAY >>> rate-limit processing of the incoming ping requests. It should be noted >>> that if a PAA or PaC which considers its connectivity lost after a >>> relatively small number of unresponsive pings coupled with a peer >>> that is aggressively rate-limiting the ping request and answer >>> messages, false-positives could result. [a14] Care should be taken when >>> rate-limiting ping request and answer messages to periodically >>> respond, and a PAA or PaC should not rely on ping request and answer >>> messages to quickly determine loss of connectivity. >>> >>> [a14]Not clear. May consider revising the senetence. >>> >>> [YO] How about this? >>> >>> " >>> Therefore, a PAA or PaC should not rely on highly frequent ping >>> request and answer message exchanges to quickly determine loss of >>> connectivity. >>> >>> " >>> >>> >> Subir> The problem here is it is either request or answer. It can not be >> both. >> If answers arrive with frequent requests, then there is no loss of >> connectivity. >> Am I correct? Also you may delete "highly" here. >> > > I think it might be good to describe it without mentioning request and > answer messages. How about this? > > > " > Therefore, a PAA or PaC should not rely on frequent ping > operation to quickly determine loss of connectivity. > Subir> Fine. > " > > > > >>> The PaC may receive a PANA-Auth-Request before receiving the answer >>> to its outstanding re-authentication request message. This condition >>> can arise due to packet re-ordering or a race condition between the >>> PaC and PAA when they both attempt to engage in re-authentication. >>> The PaC MUST keep discarding the received PANA-Auth-Requests until it >>> receives the answer to its request.[a17] >>> >>> [a17]How will PAA know that PaC has not received it? Will PaC >>> retransmit PANA-Notification-Request? >>> >>> [YO] Yes. The PAA will answer to the PNR. >>> >>> >> Subir> The question is when PaC will retransmit instead of discarding? This >> race condition may continue for a while. >> > > PNR will be retranmitted by PaC based on retransmission timer. So > most probably the first retransmitssion of PNR will break the race > condition if it does not get lost. > > Subir> Ok. >>> 5.2. Sequence Number and Retransmission >>> >>> PANA uses sequence numbers to provide ordered and reliable delivery >>> of messages. >>> >>> The PaC and PAA maintain two sequence numbers: the next one to be >>> used for a request it initiates and the next one it expects to see in >>> a request from the other end. [a18] These sequence numbers are 32-bit >>> >>> [a18]Not clear. May cosnider revising it. >>> >>> [YO] How about this? >>> >>> " >>> The PaC and PAA maintain two sequence numbers: the one to be used >>> for the next outgoing request and the one it expects to see in the >>> next incoming request. >>> >>> " >>> >>> >> Subir> How about this: >> >> "The PaC and PAA maintain two sequence numbers: one is for outgoing >> request and the other one is for incoming request." >> > > OK. > > > _______________________________________________ > Pana mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pana >
_______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
