> One of the history lessons on this list about 6 months back referred to Dag
> Belsnes' original research proving that you cannot move a data item and end
> up with both parties knowing that the data has arrived safely in less than
> 5 packets. Other people have the referents....it's not obvious to me either.
> It's probably this one from RFC 675's reference list, but to find it...?
>
> BELS74
>
> D. Belsnes, "Note on single message communication," INWG Protocol
> Note #3. September 1974.
>
>
> (In TCP, the packets are the 3-way handshake and the FIN exchange)
>
> T/TCP can achieve shorter packet sequences by leveraging knowledge from
> previous interchanges. You can get away with fewer exchanges if you are
> willing to (for instance) have the recipient not know whether the sender
> thinks the data has been transmitted safely, I think.
>
> So there is a limit to what is achievable....
Fascinating...if anyone can supply a usable reference, I'd appreciate it.
One of my assumptions about the operating environment for this protocol
is indeed that the initial receiver (i.e. the server) doesn't need to know
that the initial sender (client) received its entire transmission - it's
up to the client to retransmit if necessary. Another of the assumptions
is that both the request and the response can often be contained in a
single packet, so that (when both conditions hold) sequence numbering isn't
an issue.
For the cases when neither of the above is true, the protocol should
"upgrade" to TCP or something like it.
Keith
