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 [email protected] https://www.ietf.org/mailman/listinfo/p2psip
