Subject: [AAA-WG]: Issue 128: duplicate packet detection in failure case

From: Pat Calhoun <[email-masked]>
Date: Tue, 21 Aug 2001 13:40:23 -0700

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

Why mark packets as duplicates? The end-to-end identifier is used to identify duplicates. So, some checks are necessary regardless on whether some resources were already consumed by the first request, right? If so, then the existing scheme seems to work fine. Perhaps I am missing the problem, though.

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

I feel quite uncomfortable sending dummy packets. RADIUS has gone this way because of protocol deficiencies. Personally, adding this to Diameter doesn't make it look like a solid protocol, but rather something patched (ala RADIUS). Of course, as I stated above, perhaps I am missing the problem...

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

Why cancel pending requests? Isn't the objective to get packets to the home as quickly as possible? It seems like this issue is requesting that some additional overhead be created for reliability purposes, and again, I don't seem to see the reliability problem :(

PatC