[P2PSIP] Broken Stop and Wait Algorithm?

[Roland Bless <[e-mail]>]

Hi all,

while implementing more of the RELOAD protocol we came across
the following issue:

In sec. 6.6.3.1. Stop and Wait Sender Algorithm
http://tools.ietf.org/html/draft-ietf-p2psip-base-26#section-6.6.3.1

the spec says:
   For each retransmission, the sequence number MUST be incremented.

   Retransmissions continue until a response is received, or until a
   total of 5 requests have been sent or there has been a hard ICMP
   error [RFC1122] or a TLS alert.  The sender knows a response was
   received when it receives an ACK with a sequence number that
   indicates it is a response to one of the transmissions of this
   messages.


This would cause potential duplicates at the receiving side:

A                                B
   ---------> FramedMsg #1 ------->      ---> deliver FramedMsg #1

     |*drop* <-- Ack #1 <----------

(A: timeout
 + retransmit)

   ---------> FramedMsg #2 ------->      ---> deliver FramedMsg #2
                                              (same as above, i.e.
                                               *duplicate*).
   <----------- Ack #2 <-----------

(A: ack received,
transmit next frame)

   ---------> FramedMsg #3 ------->     ---> deliver FramedMsg #3

Given the current scheme, the receiver cannot
distinguish between the retransmitted frame (#2) and
a new one (#3). What was the reason to use _new_ sequence numbers
for retransmissions? Unless you increment the
sequence number by more than 5 for each _new_
frame, the receiving side could not filter out
duplicates.

Did I miss something?

Regards,
 Roland