> > We can say: > > > > The PAA SHOULD limit the rate it processes incoming PANA-Client- > > Initiation messages in order not to subject itself to denial-of > > service attacks. Details of rate limiting are outside the scope of > > this specification. > > > OK. > > > >>> > >> Well, the problem is that a sender of a PANA-ping that considers a node > >> dead after just a few unresponsive pings coupled with a PANA-ping > >> responder that is rate-limiting, could lead to false-positives for a > >> down link. At a minimum, please point this out. > >> > > > > By using your text: > > > > Sender of a PANA-Ping-Request that considers its peer dead after > > just a few unresponsive pings coupled with the peer that is rate- > > limiting could lead to false-positives. Implementers shall pay > > attention as they decide the number of unresponsive pings used > > for detecting dead/unreachable peers. > > > How about: > > It should be noted that if a PAA or PaC which considers its > connectivity lost after a relatively small > number of unresponsive pings is coupled with a peer that is
s/is coupled/coupled > aggressively rate-limiting > the PANA-Ping messages, false-positives could result. Care should be taken > when rate-limiting PANA-Ping messages to periodically respond, and a PAA > or PaC should not rely on > PANA-Ping messages to quickly determine loss of connectivity. > > > > > >> Also, does the PANA-ping fall within the same set of sequence numbers > >> for other PANA messages, and use the same retransmission parameters? > >> > > > > Yes it does. Do you see a particular issue with that? > > > Will, IMHO it was one of the mistakes I made with L2TP. In L2TP, the > "Hello" message is used as a "keepalive" or "ping" for the L2TP tunnel. > It is sent as any other control message. In retrospect, I really wish I > had the Hello messages on their own sequencing and retransmission > scheme, so that probing, OAM, and the like could happen outside the > operation of the critical state machine processes. For example, an > operator should feel free to send all the pana ping messages he or she > wants without threatening the operation of the session itself. If all > pings are sent reliably, in sequence with "real" messages that affect > state, then the protocol could be left struggling to keep up with pings, > missing out on more critical messages. If I understand it right, you are concerned about ping messages blocking the progress of other messages if they use the same sequence number space. But, if the peer is having hard time responding to a simple ping, probably it won't be able to process the other messages anyways. Or at least, now the first non-ping message will be the one blocking others. > > > > >>>>> The PaC and PAA MUST respond to duplicate requests as long as the > >>>>> responding rate does not exceed a certain threshold value. > >>>>> > >>>>> > >>>> What is the "certain threshold value"? Is it a certain number of > >>>> > >> packets > >> > >>>> over a period of time? Something else? I don't think an implementor > has > >>>> enough information here. Please fully describe, include defaults and > a > >>>> recommendation as to whether it should be configurable or not (in > >>>> section 9, if you like). > >>>> > >>>> > >>> Are there any guidelines from existing protocols that we can borrow? > >>> > >> What is > >> > >>> the best way to get rate limiting factored into the protocol? > >>> > >>> > >> "certain threshold value" simply leaves one guessing. If there is a > >> variable being defined here, or if you are referring to one of the > >> existing PCI values, point that out along with whether or not it should > >> be configurable as in section 9. If the certain threshold here is part > >> of generic rate-limiting which is being left unspecified, say so. > >> > > > > > > OK, it is meant to be the latter. > > > > Proposed text: > > > > The PaC and PAA SHOULD respond to duplicate requests. A request > > may be dropped due to rate limiting. Details of rate limiting > > are outside the scope of this specification. > > > How about: > > "Unless dropped due to rate limiting, the PaC and PAA MUST respond to > all duplicate request messages received." > > Unless there is some other reason to not respond to duplicates other > than rate limiting. OK. One more thing. I think we shall say "MUST process" instead of "MUST respond". For some legitimate reason, the peer may choose to silently ignore the request (e.g., message authentication code failure). Alper > > - Mark _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
