Subject: [dcp] sequence numbers on resend

From: "Patrick R. McManus" <[email-masked]>
Date: Tue, 7 May 2002 11:33:40 -0400

quickie:

4.2 defines that a sequence number increases by one (modulo 2^24) for
  every packet sent.

The spec isn't clear to me whether retransmissions (e.g. request and
response) should follow this guideline. It seems to me they should not
(and I'll work on that assumption) - I'm just noting a way that the spec
could be clearer.

-Pat

_______________________________________________
dcp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dcp

---

From: Eddie Kohler <[email-masked]>
Date: Tue, 07 May 2002 10:04:59 -0700

> response) should follow this guideline.

You're right. We need to be clearer about retransmissions at the start of a
connection.

My first instincts are:

(1) DCCP-Responses are never retransmitted. If a Response is lost, the side
that initiated the connection will retransmit the Request eventually.

(2) I'm not sure it matters, in practice, whether retransmitted Requests
have new sequence numbers. Therefore, for consistency, I would choose that
they would.

Eddie

---

From: Mark Handley <[email-masked]>
Date: Tue, 07 May 2002 10:13:26 -0700

>have new sequence numbers. Therefore, for consistency, I would choose that

The advantage of this is that it's easy to tell which Request packet
got through, so you can initialize RTT measurements correctly.  The
disadvantage would be that you have to be prepared to accept a
Response acking any of the Request sequence numbers you've sent for
this connection.  So using new sequence numbers seems to be a win on
balance, but it is slightly more complex.

 - Mark

---

From: Eddie Kohler <[email-masked]>
Date: Tue, 07 May 2002 10:21:51 -0700

> this connection. 

This isn't so hard if you just increase the Request sequence number by one
for each retransmission, like you'd do for any other packet on the
connection.

Eddie

---

From: "Patrick R. McManus" <[email-masked]>
Date: Tue, 7 May 2002 13:48:40 -0400

> that initiated the connection will retransmit the Request eventually.

correlary: t3 needs to be very large. This could lead to some pretty
big tables of timers not associated with real sessions.

> have new sequence numbers. Therefore, for consistency, I would choose that

I'd argue against it for a few reasons:

  1] the above - using the same ISN would let you use the same
  connection and not have orphaned timers.

  2] (rvcd_ackn == local_isn) has to match on each side to complete
  the handshake.. extending that to (rcvd_ackn is_in
  list_of_local_isns) is an implementation hassle - requiring state
  maintenance for each resend.

  3] least surprise - in TCP a retransmit is a RE-transmit, the same
  TCP level data is simply sent again. this way you only have to worry
  about dups not which one is "right".

---

From: Eddie Kohler <[email-masked]>
Date: Tue, 07 May 2002 11:01:50 -0700

>   connection and not have orphaned timers.

The connection is uniquely identified by the port numbers [and Service
Name]. A retransmitted Request will have the same port numbers, so there's
only one connection, and no orphaned timers.

>   about dups not which one is "right". 

Well, in DCCP, every packet increments the sequence number, including pure
acks (and retransmitted pure acks). Therefore I think incrementing the
Request sequence number would surprise the least.

>   maintenance for each resend.

I agree with this concern, although I don't think the hassle would be that
serious. It's not a new kind of state, after all; it's just like the state
DCCP endpoints maintain for established connections.

Again, it doesn't seem like a big deal either way. I prefer incrementing
the sequence number for internal consistency, and because it provides more
information to the endpoints.

With incremented sequence numbers, the endpoints need to handle old (=
delayed) and duplicated Requests and Responses. With identical sequence
numbers, the endpoints need to handle duplicated Requests and Responses.
The logic will be basically the same. Doesn't seem that much easier.

Eddie

---

From: "Patrick R. McManus" <[email-masked]>
Date: Wed, 8 May 2002 12:39:16 -0400

more thoughts on resending requests - what about requests with data?
Warning, this scenario may not be fully baked - I've just started
toying with it.

the state diagram says you only count that data once (requests outside
of LISTENING are ignored)..

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

..

so the client (A) now has only 1 of 2 xmitted packets
ack'd.. this is fine, as it was true when B generated the ack
vector.. 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.

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. 

-Patrick

---

From: Mark Handley <[email-masked]>
Date: Wed, 08 May 2002 09:58:45 -0700

>however new ack vectors at times > 6 will still represent

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.

>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