Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP
From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Acking out-of-order packets?
Message-ID: <19880303204848.4.DCP@SWAN.SCRC.Symbolics.COM>
Date: 3 Mar 88 20:48:00 GMT
References: <[A.ISI.EDU].3-Mar-88.00:44:19.CERF>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 9

[I wasn't on the design team.]  I would strongly suggest that any
next-packet ACKs generated by out of order segments wait until the
network input queue is empty.  For a multitude of reasons, the medium
or the implementation may reverse some packets on you.  (E.g., in past
releases, the 3600 had LIFO transmit and receive queues, but since
transmitting a packet is fast the transmit queue is effectively FIFO,
and the receive queue is processed by a process/task.  We now reverse
the receive list.)  I agree that encouraging the sender to retransmit a
packet that should have arrived helps performance.  I'm asking that
people be careful in making the "should" determination.