VARIOUS STUFF TO DO FOR ITS TCP:

TCP should remove the SYN segment from its retransmit queue after
	it gets ACKed (see handling of SYN-SENT state).
	Also, TCP should probably not compact a SYN segment with one
	containing text, since this fucks up some other systems.

TCP WHYINT is wrong about # bytes of input available.  This was
	causing TELNET to wedge up; fixed by making it use no-hang
	SIOT, but still WHYINT ought to be correct.

	Should probably also decide whether the output val (# bytes
	of room) is correct too.  Old problem of window vs # segs
	vs sys buffer concept.

Incoming ACKs should prevent retrans from aborting connection, since
clearly it is still alive, just doesn't have room for our stuff (which
is possibly overflowing its window).

Return an ACK immediately in response to large packet, but delay
	if amount of data is small.  This helps to optimize
	TELNET and FTP properly.

Note Clark suggs on windowing/ACKing.
	If input data seg doesnt have PUSH, don't send ACK, but set
	a timeout for sending ACK.  Send ACK when:
		PUSH is seen
		outgoing seg forced out (new or retrans)
		timed out

Interrupt-driven output buffering.  Device driver (ie IMP) should
	scan TCP conn tables to generate a new datagram on the fly.
	This lets us send absolutely uptodate stuff and is all-around
	more efficient.  Doesn't use that much more time at PI level
	since datagrams have to be sent with NETOFF anyway.

TCP should momentarily queue out-of-order segments.
	This implies yet another list.  Total of input list and OOO list
	should not exceed 5.  When valid dgm is seen, it should check
	for existence of OOO list and try to re-hack the first thing on
	that list.  Must avoid infinite loop though.

Provide way for output IOT to specify URGENT, and 
Handle URGENT when received on input.