[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

    > From: Detlef Bosau <detlef.bosau at web.de>

    > Perhaps we talk at cross purposes here.

Perhaps! :-)

    > 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.

Right. That's what RFC-793 calls the "retransmission queue" (a poor
name, perhaps).

If you look for the word "queue" in the text, there are only two queues on
the output side (other than queues in the interface between the application
and the OS): the "retransmission queue" (perhaps better named the
'unacknowledged data queue'), and the "network output queue", i.e. the device
driver 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.)

Yes... And?

    > The one question is: how do we implement Karn's algorithm correctly?
    > ...
    > what is the difference then to a GBN strategy, which was "never done"
    > by TCP Tahoe, as I was told off list?

You're asking about much later TCP practice and implementations; sorry, I
cannot help with those.