[ih] internet-history Digest, Vol 84, Issue 4

[Detlef Bosau]

Am 27.05.2014 05:30, schrieb Noel Chiappa:
>     > From: Detlef Bosau <detlef.bosau at web.de>
>
>     > I should read texts much more carefully.
>
> This is rather an ironic comment, given the next...
>
>     >>   if the retransmission timeout expires on a segment in the
>     >>   retransmission queue, send the segment at the front of the
>     >>   retransmission queue again [and] reinitialize the retransmission
>     >>   timer
>
>     > Do I understand this correctly: When the packet is retransmitted, a
>     > copy is _appended_ to the retransmission queue?
>
> If you would examine RFC-793, you would see that by "retransmission queue" it
> means 'un-acknowledged data queue'.

May I just quote RFC-793, section 2.6: "

When the TCP transmits a
  segment containing data, it puts a copy on a retransmission queue and
  starts a timer; when the acknowledgment for that data is received, the
  segment is deleted from the queue.  "

> So your question makes no sense, on two grounds: first, the data being
> re-transmitted is _already_ in that queue; second, it is at the _start_ of
> that 'queue' (buffer, actually - although it's implementation-specific how
> un-acknowledge data is held - Dave Clark did a TCP for use with User TELNET
> awhich kept un-acknowledged data in a shift register :-), adding it at the end
> would be an error.

Perhaps we talk at cross purposes here.

What you name "unacknowledged data queue" is a vector or arry, whatever,
which is basically a FIFO queue of bytes.
The first byte in this queue is the one which corresponds to "snd.una",
the first unacknowledged byte in flight. (There is no acknowledged byte
in the unacknowledged dataqueue, otherwise it wouldn't be the
unacknowledged data queue.)

However, this leads to the conjecture, that unacknowledged packets are
not stored in some "retransmission queue" but (as I implemented this
myself in my simulator) we keep an unacknowledged data queue and
packets, which require retransmission, a reconstructed from this queue.
(Just as Louis pointed out.)

The one question is: how do we implement Karn's algorithm correctly? (As
we simply don't know whether a RTT sample belongs to a retransmitted
packet because we don't keep a list of retransmitted packets. We keep a
queue of unacknowledged data, no more!)
And the other question is, refer to my response to Louis some minutes
ago, what is the difference then to a GBN strategy, which was "never
done" by TCP Tahoe, as I was told off list?

>
> Look, you need to understand how primitive our understanding, algorithms, etc
> were when RFC-793 was written. There was no sophisticated algorithm associated
> with re-transmission: when the (sole) re-transmission timer went off, the code
> re-sent the oldest un-acknowledged data again. That's all. Full stop.
>
> If you read RFC-793 (and the other ones I have mentioned), you will get a
> good sense of our level of understanding, how primitive many of our
> algorithms, etc were at that point.


I have no problems with that.

But I have problems when I submit papers and these are rejected because
reviewers complain about missing comparisons to other TCP flavours.

And my general impression is that we are better than lawyers here.

You know the saying: If you ask two lawyers one question, you will get
three answers.
If we would rephrase this for CS guys, I would ask: "Only four?"

Perhaps, we should introduce a understanding disambiguator as in C++:

Noel_Chiappa::Tahoe ()
Detlef_Bosau::Tahoe()
Craig_Partridge::Tahoe()
.....

;-)
 
> 	Noel


-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de