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: Thu, 23 Nov 1989 18:27:00 -0000
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: type 2 protocols
To: mtudwg
Message-Id: <89/11/23
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 proposal! Steve
- type 2 protocols Steve Deering