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
>>
>>
>>    
>>