[HECnet] "Dropped by adjacent node" ....

[Johnny Billquist]

On 2014-05-28 15:56, Paul_Koning at Dell.com wrote:

On May 28, 2014, at 9:40 AM, Johnny Billquist <bqt at softjar.se> wrote:

On 2014-05-28 15:33, Paul_Koning at Dell.com wrote:

...
DDCMP is a data link layer that deals with packet loss.   It also deals with reordering, within reason, by treating it as packet loss, just as NSP did until Phase V.   It should be ok with limited duplication as well     though duplication is not one of the supposed characteristics of UDP.

Duplication is definitely a possible event with UDP. It happens from time to time. It's essentially because duplication is possible with IP. UDP is just IP with ports and a checksum (if you are lucky). And IP makes no promises at all. Packets might not arrive, might arrive out of order, become duplicated, delayed, or even corrupted.

Note that I meant the DDCMP protocol, not the DDCMP point to point service.   In other words, the UDP packets would carry DDCMP frames, with DDCMP header (including sequence number and all that).   I think SIMH has that right now, in V4.0 DMC emulation.

Ok. So if I understand correctly, DDCMP is guaranteeing the delivery of data between the two points. Data will arrive in order and without any loss or other confusion, as seen by the layers above DDCMP?

Yes, just as with TCP.   The usual disclaimers apply.   For example, dups or reorders are detected only up to the wrap point of the sequence number space.   Corruption is caught only up to the capabilities of the CRC being used.

Also,    guaranteed delivery    is a commonly used term.   A more accurate term would be    guaranteed delivery or notification of failure   .   Connection oriented services like DDCMP and TCP and TP4 and NSP will deliver the data stream intact to the other end, OR they will tell you that they could not do so.

Seems like UDP could work then, but maybe TCP would be better?

Not clear.   If things get reordered or delayed to the point that the DDCMP sequence number space is no longer sufficient, then TCP would help.   It makes things somewhat more complicated (as Rob Jarratt pointed out) because TCP introduces the asymmetry of    who connects    while DDCMP does not have than and neither does UDP.

Right. However, I also wonder if the retry and recover mechanisms in TCP might be faster and more efficient than what DDCMP do. But like I said, I have not looked, so I'm just guessing.

	Johnny

-- 
Johnny Billquist                                   || "I'm on a bus
                                                                  ||   on a psychedelic trip
email: bqt at softjar.se                         ||   Reading murder books
pdp is alive!                                         ||   tryin' to stay hip" - B. Idol