Subject: [P2PSIP] Broken Stop and Wait Algorithm?

From: Roland Bless <[email-masked]>
Date: Fri, 18 Oct 2013 21:46:15 +0200

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

---

From: "Michael Chen" <[email-masked]>
Date: Fri, 18 Oct 2013 15:43:20 -0700

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" <[email-masked]>
Date: 10/18/13 12:46 pm
To: "P2PSIP WG" <[email-masked]>

Hi all,

 
 the spec says:

 
 A B
 
 |*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)

 
 Did I miss something?
 
 Regards,
 Roland
 _______________________________________________
 P2PSIP mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 21 Oct 2013 10:24:19 +0200

Hi Michael,

> is the nature of the UDP transport. By comparison, ACK is never repeated.

Thanks for clarification. I guessed that it's up to the upper layers
to deal with it, but IMHO this actually an unnecessary potential
additional source of duplicated fragments besides IP packet duplication
and if you don't care about duplicates you can even leave out sequence
numbers in the stop and wait protocol...

Detecting duplicated fragments may not always help:
If you have a single fragment only, you'll immediately pass it
up to the message transport for instance. So in this case you need
to check for duplicate transaction IDs or rely on the implementation
(sec. 6.2.1.):
   Receiving nodes MUST generate semantically equivalent
   responses to retransmissions of the same request (this can be
   determined by transaction ID) if the request is received within the
   maximum request lifetime (15 seconds).

> build the FramedMessage.received bitmask for the last 32 fragments.

Yes, I read that part, so that you can estimate loss rates
or RTTs.

>     --------- Original Message ---------
>     Subject: [P2PSIP] Broken Stop and Wait Algorithm?