Subject: [AAA-WG]: [issue] duplicate packet detection in failure case (draft-ietf-aa a-diameter-07.txt)

From: [email-masked]
Date: Tue, 21 Aug 2001 16:03:08 +0300

Hi Pat,

Resending this one, due to mail failure ... 

Issue: duplicate packet detection in failure case 
Submitter name: John Loughney
Submitter email address: [email-masked] 
Date first submitted: August 20, 2001 
Reference: 
Document: Base 
Comment type: T 
Priority: 1 
Section: In section 9.4  Fault Resilience,
Rationale/Explanation of issue: 

The text in 9.4 may not be sufficient in failure cases. Some text is needed
to describe how to handle the failure case.

Requested Change: 

Additional text should be added to discuss 

The sending party sends the (maximal amount = the used send window size)
unacknowledged packets (after a link failure) to the next available
secondary/tertiary/etc. alternative recipient node (CG), with a mark that
they are potential duplicates, to wait there for a final decision. 

After the original link comes up, the original sender tests with empty dummy
packets if the original recipient would acknowledge those packet numbers as
"already successfully handled" or "new". 

Then the sender just announces the secondary node which waiting packets it
may release towards the final destination (like BS), and which waiting
potentially duplicated packets to cancel (since they had already been
successfully handled by the original recipient node just before its link
went down.