Re: [dcp] sequence numbers on resend

>t0: xmit A->B Req    SN=0 with data
>t3: xmit A->B Req    SN=1 with data
>
>t5: rcv  A->B Req    SN=1 with data
>t5: xmit B->A Resp   SN=0 ack=1 vector=0,192
>t6: rcv  A->B Req    SN=0 with data (dropped as we're in APP-ACCEPT)
>
>t7: rcv  B->A Resp   SN=0 ack=1 vector=0,192

>however new ack vectors at times > 6 will still represent
>sn=0 as unreceived (which is untrue) and will impinge on A's cwnd for
>a while.

How does the receiver even know that sn=0 was sent?  The ack vector it
sends at t5 wouldn't cover 0 because the request ISN was 1.  However
the sender knows it was sent, and should act accordingly.

>if A retransmits with the same isn (because it's the same data he is
>only expecting one ack bit for) this problem goes away. 

The flipside is that if you send with the same ISN, in the same
scenario, you also can't tell if the first packet was lost or not.
The sender MUST assume it was lost (it sent two SYNs, got one ACK).

So the problem is very similar, but there's less information if you
don't increment ISN for the sender to go on.

If you want to solve this corner-case problem correctly, I think you
need to increment the ISN, and in this case back off the start of the
ack-vector to 0 when you get the delayed request at t6 (you don't
completely ignore it - it just doesn't cause a state-machine
transition).

Cheers,
	Mark

_______________________________________________
dcp mailing list
dcp@ietf.org
https://www1.ietf.org/mailman/listinfo/dcp