type 2 protocols

Steve Deering <deering@pescadero.stanford.edu> Fri, 24 November 1989 02:29 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA10943; Thu, 23 Nov 89 18:29:28 PST
Received: by decwrl.dec.com; id AA19202; Thu, 23 Nov 89 18:28:59 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA01311; Thu, 23 Nov 89 18:28:51 PDT
Date: 23 Nov 1989 18:27-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: type 2 protocols
To: mtudwg
Message-Id: <89/11/23 1742.002@pescadero.stanford.edu>

When Jeff posted my MTU Discovery proposal to this list, he mentioned
that the stuff I wrote on "type 2 protocols" should be ignored.  In
case any of you are puzzling over that, here are some fragments of
a message exchange between Jeff and myself that occurred before the
list was started up, in which I realize the flaws in my reasoning
(and in my attribution of credit for the invention of "my" scheme)...

	From: Steve Deering <deering@pescadero.stanford.edu>

	One thing I neglected to mention in my draft RFC is that a sender
	should never exceed the default or negotiated MSS, that is, it
	should bound its packet size by MIN (assumed-MTU, MSS).

	From: Steve Deering <deering@pescadero.stanford.edu>

	On further reflection, I've realized that TP-4 is not really a
	"type 2" protocol.  The "maximum TPDU size" negotiated at connection
	setup time is just like TCP's MSS.  A sender is always allowed to
	send data packets smaller than the negotiated max, if the path MTU
	is discovered to be smaller.  The only way in which TP-4 is
	significantly different from TCP is that in TP-4, restransmitted
	packets must be identical to their originals (i.e., they cannot be
	shortened if the MTU shrinks between the time the original is sent
	and the time it is retransmitted).  TCP, on the other hand, can send
	fewer bytes in a retransmission, thanks to its use of per-byte
	sequence numbers.

	I wonder if there really are any type 2 protocols?  I could imagine
	a version of NFS, say, that negotiated a "block size" at session-
	establishment time and then insisted that all subsequent data packets
	be exactly that length (i.e., insisted that blocks be read/written
	as a single unit).  Who knows.  Probably not worth us worrying about.

	Also, on re-reading your "Fragmentation Considered Harmful" paper, I
	find that you and Chris actually invented my entire scheme, including
	the special flag in the IP header.  I'll have to upgrade my
	acknowledgement of your work (although, I *think* I came up with my
	scheme independently).  Anyway, I'll take the credit or blame for
	promoting it, since you didn't.

	From: mogul@decwrl.dec.com (Jeffrey Mogul)

	I suspect that it would take some perversity to design a "Type 2"
	protocol that insists on non-shrinking MSS.  NFS, for example,
	allows arbitrary-length block writes even though a decent client
	would probably try really hard to do things in some natural size.
	If NFS required certain block sizes, for example, you would have
	a hard time writing a partial block at the end of a file ... which
	might be OK for RT-11 based servers, but not for Unix.

	From: Steve Deering <deering@pescadero.stanford.edu>

	I was actually thinking of the issue of writing a block in the
	*middle* of a file.  A block-oriented protocol might have no way
	to identify a range of bytes to be written, so that any block
	*except* the last would have to be written as a complete unit.
	I think this is actually the way the V I/O protocol works.  Anyway,
	this is only a problem if there is no way to split the parts of a
	block across multiple packets, which could be viewed basically as
	a bug in the protocol.  I shouldn't be trying to justify type 2
	protocols; if they don't exist, all the better for my MTU discovery