[HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10

[Paul_Koning at Dell.com]

On Jan 6, 2013, at 8:55 PM, Gerardo Cacciari wrote:

On Sat, 5 Jan 2013 01:31:36 +0000, you wrote:

Finally, in the DMC a buffer corresponds one to one with a DDCMP packet (its 
implementation of property 3). That's required -- all DECnet protocols are 
packet oriented and packet boundaries are meaningful.   There are no byte 
stream protocols in DECnet -- TCP is the only protocol among all the 
networking protocols I know of that made that horrible design error.

Sorry to bother you, but right in these days I'm reading and learning
something more about transmission protocols (such as BSC, SDLC, and DDCMP),
and your statement about that TCP design error tickled my curiosity.

I know that BSC and DDCMP can be defined as character oriented protocols,
while things like SDLC (and all its derivatives) are bit oriented; there are
other differences but this is the most striking one. But let's not digress.

I'd relate TCP to DECnet NSP, rather than to DDCMP, and if I'm not wrong both
protocols (and DDCMP too) have variable length packets, according to how much
data they have to send at the moment. So, can't they both be defined byte
stream protocols? Or maybe are you referring to the fact that while NSP and
DDCMP have a per-packet acknowledgement, TCP acknowledges single bytes and so
can theoretically acknowledge just the first N bytes of a given packet?

Yes, TCP has variable length packets, as do the other protocols.

The essence of "stream oriented protocol" is not in the packet format.   Instead, it is in the definition of the service provided to the application.

In TCP, the service provided is a stream of bytes delivered to the other end.   The stream has no structure. 

In every other networking protocol (including, ironically, UDP) the service provided is delivery of a sequence of packets to the other end.   A packet is a number of bytes AND a specific packet boundary.

For example, if in TCP I send 10 bytes then 20 bytes, the receiver may see 30 bytes delivered all at once, or a delivery of 5 bytes followed by 25 bytes, or 6 deliveries of 5 bytes each.   Some of those are not likely in practice, but all are valid.

On the other hand, in DECnet (or UDP, or ISO transport) if I send a 10 byte packet then a 20 byte packet, the receiver sees a 10 byte packet followed by a 20 byte packet.   Nothing else is possible.

All applications need structured data of some sort.   So what happens is that every application has to make up for the fact that TCP doesn't do a packet service by layering a packet delimiting scheme on top.   Often that comes in the form of a header that contains a data length, then you count off that many bytes, and then you look for another header.   If you ever get out of sync, you end up looking for a header in the wrong place and the protocol won't recover until you close the connection and restart.

Also, in the real world under the covers, you always have packets.   So you would think that in reality, a high speed application (like iSCSI) could just assume that its headers are always found at the start of TCP buffers.   And yes, that's a valid optimization, but you can NOT rely on that being true 100% of the time, because it's only a "likely" behavior, not a guarantee that's part of the TCP service definition.

By contrast, if you implemented iSCSI on top of DECnet, or OSI, you would simply have the iSCSI PDUs starting at the start of a transport layer SDU, and this whole mess would disappear.   Your code would be much smaller and more reliable because you no longer have to allow for the "unlikely" case of application PDUs starting in the middle of a TCP data delivery, or worse yet, straddling a boundary.

Incidentally, there's a successor to TCP called SCTP that has packet service, and it would be a great solution to all this if only it were in general use -- but it isn't.

	paul