[e2e] Some questions about TCP.

[Ted Faber]

On Sun, Nov 22, 2009 at 08:04:45PM +0100, Detlef Bosau wrote:
> Hi to all.
> 
> The following questions may be stupid - however, the most stupid 
> questions are the never asked ones ;-)

Jon Crowcroft's right, you should spend some time with Stevens.  I also
suggest that if you're going to be studying TCP, a good place to start
your trip through the RFCs is RFC4614, the TCP Roadmap.  You can find it
here: http://www.rfc-editor.org/rfc/rfc4614.txt .  While any such
roadmap is quickly out-of-date, it is a fairly recent assessment of the
TCP standards and important experimental RFCs conducted by some TCP
gear-heads with impeccable credentials (and I include the tcpm working
group here, in addition to the authors).

The fast retransmit procedure is somewhat intricate, even without
selective acknowledgements, and it's well worth studying Stevens'
detailed, well written description of it.  Jacobson's original paper is
also worth a look, and referenced in the roadmap.

But...

> 
> 1.: Recently, I was told, however I did not find a reference in some 
> RFC, we had two distinct packet types in TCP:
> - those _with_ payload, which are _data_ _segments_,
> - those _without_ payload, which are _acknowledgements_.
> 
> If this is correct, I would appreciate some reference.

It's not.

There is only one kind of segment, and during a connection's ESTABLISHED
phase (the phase one cares about in congestion control) they all have
ACKs.  Note that each endpoint acknowledges the last data from the
other.  Endpoint A's packets contain the last byte received from
endpoint B and vice versa.  If one of those endpoints sends no data
after acknowledging the other side's SYN+ACK segment, the ACKs from the
other repeatedly acknowledge the last packet of the three-way handshake.

One point you seem to be having trouble with: when an endpoint receives
an ACK and that endpoint has no data outstanding (that is, all the data
it has sent to the other endpoint has been previously acknowledged), it
is safe to ignore the ACK. (OK, there are reasons to check the ACK to
make sure your connection has not been hijacked or otherwise disrupted,
but for the purposes of congestion control, you should ignore it).  A
duplicate ACK is only interesting to the congestion control system when
the endpoint has sent data and is uncertain of that data's fate.

It's difficult to lose data you have not sent.  Imagine you got three
duplicate acks of the last bit of acknowledged data you'd sent: what
would you resend in the fast retransmit phase?

> 
> 2.: RFC 2581 states, tat in slow start state CWND is incremented by 
> _new_ acknowledgements, not by duplicate acks.
> The same holds true in congestion avoidance state.
> 
> Question: Why is CWND is not incremented for dupacks? When I think about 
> it, I can find arguments for both ways. So, I would like to here the 
> rationale for the "standard version".

If the duplicates are caused by reordering, the discrepency will be
handled when the ACKs for the out of order packets arrive at the sender.
If the packet is lost, the window will be inflated to account for them
in the fast retransmit procedure.  This is a little more hand-wavey than
the rest of the procedure (and there are additional experimental
procedures for recovering from reordered packets).  Again, Stevens
traces these paths in more detail than the RFC.

> 
> 3. I do not quite understand the fast retransmit procedure in RFC 2581.

That seems to be so.  Again, I believe Stevens discusses it in detail.

> To my understanding, the fast retransmit retransmits the "one" lost 
> segment indicated by last ack and does _not_ a go back n.

In the absence of selective acknowledgements, the sender does a
go-back-n when there is a fast retransmission.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20091123/45ceee94/attachment.bin