Re: [P2PSIP] Broken Stop and Wait Algorithm?

Roland,

Your fragment re-assembler must tolerate duplicate fragments, because it
is the nature of the UDP transport. By comparison, ACK is never repeated.

The sequence number must always incremented so that the receiver can
build the FramedMessage.received bitmask for the last 32 fragments.

Thanks

--Michael
--------- Original Message --------- Subject: [P2PSIP] Broken Stop and Wait Algorithm?
From: "Roland Bless" <roland.bless@kit.edu>
Date: 10/18/13 12:46 pm
To: "P2PSIP WG" <p2psip@ietf.org>

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
 _______________________________________________
 P2PSIP mailing list
 P2PSIP@ietf.org
 https://www.ietf.org/mailman/listinfo/p2psip