Re: CARD: handling of sequence numbers
Marco Liebsch <[email protected]> Wed, 15 Oct 2003 17:39:23 +0200
| Newsgroups | gmane.ietf.seamoby |
|---|---|
| Organization | NEC Europe Ltd. |
| Message-ID | <[email protected]> |
Henrik Petander wrote: >Hi Marco, > >On Fri, 10 Oct 2003, Marco Liebsch wrote: > > > >>To your last point: Is an AR really required to distinguish a >>"resent" Request from a "new" one? >> >> > >Yes, if AR-AR resending is implemented, since AR will set a new AR-AR >resend timer when it receives a "new" request from MN. It should not do >the same for resends from MN for which it already has a timer. > That means an AR should refrain from creating a new timer in case it is a retransmit (which is reasonable), but should create a new timer in case a MN sends two requests directly after each other, right? The current spec allows the MN to send only one request per CARD_RETRANSMISSION_INTERVAL, which is set to 1 second. In case we keep 1 second also for the MN_AR_TIMEOUT, there should not be a conflict, right? Otherwise, we could also let the MN "flag" a CARD REQUEST in case it is a retransmission. But I guess this introcuced more complexity compared to the benefit. What do you think? > > >If MN increases the sequence number for each resend, then AR needs >to be able to differentiate the new and resent messages by other fields. I >don't think this is a problem, though, since AR can just compare the >L2-ids of the messages. > In a MN_AR CARD Request there is not necessarily to be a L2_ID present. But don't you think we get rid of this problem with the updated design of allowed retransmissions, where, according to your recent proposal, the MN-AR timeout should cover all possible retransmissions between ARs? Or, as described above, we could have a flag set in MN-AR CARD_REQUEST in case of a retransmit... (???) What do you think? marco > >Henrik > > > > >>marco >> >> >> >> >> >>_______________________________________________ >>Seamoby mailing list >>[email protected] >>https://www1.ietf.org/mailman/listinfo/seamoby >> >> >> >>