Talk:Reliability (computer networking)

TCP/IP

For example, the TCP/IP protocol is connection-oriented, with the virtual circuit ID consisting of source and destination IP addresses and port numbers.

The virtual circuit article says [TCP] is not an example of virtual circuit application, although it is connection-oriented.

So what is correct? --Abdull 18:25, 8 May 2007 (UTC)

Addded recent entry to reliable multicast protocol TODO: cover any other arrivals Hulkeypoo (talk) 09:28, 30 May 2008 (UTC)

Meaning of "reliable delivery"

I am coming to the conclusion that I have a problem with the way the term “reliable delivery” is currently being used. While not (any longer) explicitly used in this article, it is used widely elsewhere, and has come to have a meaning that is, at best, misleading. An example of this use is in the lead section of the article on the Transmission control protocol (TCP). This states “TCP provides reliable, ordered and error-checked delivery…”. And, while not explicitly stated in this reliability article, this idea of “reliable delivery” on the part of such protocols as TCP is, at least, tacitly supported.

My problem stems from my research into the niche use of packet switched networks in firm real-time systems. These systems require that at least some of the data (that which is critical to their operation) be delivered with a low probability of loss. Basically the probability of the loss of consecutive instances of a specific, critical data transfer has to be down at the level required for the level of criticality of the data, e.g. not more often than once in a million hours of operation for flight safety-critical data. This is complicated by the fact that these data must be delivered with a maximum latency, i.e. within a deadline, as data delivered after its deadline is useless and thus equivalent to a failed delivery. This deadline requirement then makes it difficult to use retries to recover from, e.g., bit errors induced in the physical layers, but that’s bye the bye.

The problem itself is that we call this “reliable delivery”, i.e. we rely on the data being delivered. Whereas, what seems to be being meant by “reliable delivery” in the IP context is that the data is delivered or the sender is notified otherwise. I accept that this represents a “reliable service”, in that there are only two possible outcomes. However, I don’t accept that you can legitimately call this “reliable delivery” when one of those outcomes is that you are notified that it has not been delivered. The only way that I could accept this as “reliable delivery” would be if there were a defined limit on the ratio between the two results, which is only the same as giving a probability for delivery (which can be relied on). But as loss rates with, e.g., TCP are entirely indeterminate, depending as they do on the actions of other users connected to the same network segments, there is no obvious a limit on the ratio that can be relied on and thus no way delivery itself, as one of the possible outcomes, can legitimately be called reliable : all that such reactive protocols can do, at best, is to maximize the likelihood of delivery for any given network condition, i.e. enhance the probability of delivery ; they do not offer any specific value for this probability, and if the network is sufficiently overloaded (e.g. with traffic claiming the highest priority), the probability of delivery can always approach zero.

So, I’m wondering if there should at least be a section in this article to address this issue, i.e. that the use in IP circles of “reliable delivery” is less than strictly accurate, and maybe some reference to the real-time data transport requirement for the reliability with which the data is actually required to be delivered. Some existing protocols that can legitimately be described as providing “reliable delivery” are MIL-STD-1553B and STANAG 3910 for buses, and Time Triggered Ethernet and AFDX for PSNs – though it is perhaps less than clear how you actually prove reliable delivery with AFDX. However, since I’m only really comfortable with the latter aspect, what “reliable delivery” means in the real-time context, I thought I’d canvas opinion here, before being quite so bold.

Graham.Fountain | Talk 10:13, 12 August 2014 (UTC)

You are correct that there is a specific network engineering meaning of reliable that this article is trying to cover: the data is delivered or the sender is notified otherwise. Reliable is definitely casually used in network engineering for other concepts and this should be made clear. ~KvnG 14:32, 15 August 2014 (UTC)

I have started to try to put together a section on the peculiarities of reliable and timely delivery for real-time systems, at User:Graham.Fountain/reliable delivery in real-time systems. It's got some references already, but it might need a couple more. However, there are currently no other usable references to DEFTNet, apart from Dr Charlton et al's IEEE paper, which is already cited.

Graham.Fountain | Talk 12:05, 18 August 2014 (UTC)

I've stuck the real-time reliability section in at the end.

Graham.Fountain | Talk 13:48, 3 February 2015 (UTC)

Latest revision as of 16:16, 25 October 2017 by Kvng

I think the first paragraph is now circular, as it defines reliability as assurance and then says they are synonyms. It is, however, true that it was vague before, but I don't think it's much less vague now.

I think the basic problem stems from the fact that most people think that reliable protocols like TCP guarantee delivery. This has been made very clear to me in the course of the work I do with real-time data transport. Whereas, as we know, what they actually do is improve the probability of delivery – a single re-try roughly squares an already small probability of loss – and report the success or failure in delivering the data. In a sense, it’s the difference between “reliable delivery” and “reliable transport”: what you get sold is the first; what you actually find in the box when you get it home, if you bother to look, is the second.

The problem, for me, that it is very easy to read "provides assurance of the delivery of data" as meaning that it makes it certain that data will be delivered, i.e. what the Oxford dictionary gives as the second meaning of assure: "Make (something) certain to happen". Whereas, what it really should say is more clearly related to the first meaning of assure: "Tell someone something positively to dispel any doubts." If I understand this correctly, the “make certain” use is as a simple transitive verb and the “tell someone something positively” is in a dative use, with both a direct and indirect object – the “someone” and the “something”. However, while I can see that there are arguably two objects in “delivery of data”, I’m far from certain it’s obvious when it’s inflected like that.

So, I think that issue of assurance as “notification of delivery status” needs to be stated positively, rather than by double negative, as it currently is – “an unreliable protocol… does not provide notifications to the sender as to the delivery”.

@Graham.Fountain: I'm glad, at least, that I did not make things worse. I agree we need to rework this so that it is not circular and I see that using "assurance" to do that is not the answer. There is some material in Reliability (computer networking) § Reliability properties that approaches a definition in the manner you are requesting. There is a citation on the first paragraph of that section by I am unable to verify it. I will see if I can find a more accessible source. ~Kvng (talk) 14:09, 29 October 2017 (UTC)

@Kvng: There is an online copy of that book (sixth ed) at [1] - I'm not sure if it’s a legit copy in terms of copyright, but for this purpose I reckon it's okay to use. I'm currently having a look at it; however, my immediate reaction is that it does not appear to contain the definition it's used as a citation for. Rather, it appears to be readable as meaning reliable = guaranteed delivery. However, I've only read the bits found by a search for "reliab", so I want to do a bit more reading.

So, I think some reference for a definition of reliable in this context is needed - I think the one given in the subsection you point to is correct, but not an axiom, so it needs a reference. However, I think that might be hard to get from anything but a primary source, like an RFC. Graham.Fountain | Talk 11:18, 30 October 2017 (UTC)

@Graham.Fountain: Thanks for the book link. There is a definition for "Reliable Data Transfer" on page 91. This describes a guaranteed delivery and does not mention the possibility of an unrecoverable communications error or notification of the application of such. This does not match what's said in the cited statement at the beginning of Reliability (computer networking) § Reliability properties. There's no page number on the citation so these things could be described elsewhere in th book. For now, I have marked this with {{fv}} in the article. ~Kvng (talk) 17:06, 2 November 2017 (UTC)

Short description

Per WP:SDLENGTH, the short description of this article should be shortened immensely, ideally to around 40 characters. I've temporarily shortened it to "Ability of a computer network protocol" from "Ability of a computer network protocol to notify the sender of whether delivery of data was successful".

@Kvng notifying you of this before you revert my edit ~ Eejit43 (talk) 04:10, 29 December 2022 (UTC)

I agree that the original was unnecessarily long. Your change to "Communications protocol" was short but wrong. I am now suggesting "Protocol acknowledgement capability" because it is short enough and doesn't repeat anything that is already in the title. One potential problem: acknowledgement does not appear in the lead. ~Kvng (talk) 04:26, 29 December 2022 (UTC)

No yes I completely agree. I don't recall writing that but I have no clue what I was thinking! I like your change, it is very short and concise! "acknowledgement" not appearing in the lead isn't the worst thing in the world, but I think it would actually be good to include that in the article. ~ Eejit43 (talk) 05:13, 29 December 2022 (UTC)

Merge from Fault-tolerant messaging

Fault-tolerant messaging is unsourced and appears to cover the same topic as this article. ~Kvng (talk) 18:58, 4 August 2024 (UTC)