Reliability (computer networking): Difference between revisions

Revision as of 19:38, 1 May 2020

Revision as of 14:06, 4 May 2020

Line 5:

Reliable protocols typically incur more overhead than unreliable protocols, and as a result, function more slowly and with less scalability. This often is not an issue for [[unicast]] protocols, but it may become a problem for [[reliable multicast]] protocols.

[[Transmission Control Protocol|Transmission Control Protocol]] (TCP)]], the main protocol used on the [[Internet]], is a reliable unicast protocol. [[User Datagram Protocol|UDP]] is an unreliable protocol and is often used in [[computer games]], [[streaming media]] or in other situations where speed is an issue and some data loss may be tolerated because of the transitory nature of the data.

Often, a reliable unicast protocol is also [[connection-oriented]]. For example, TCP is connection-oriented, with the [[virtual circuit|virtual-circuit]] ID consisting of source and destination [[IP address]]es and port numbers. However, some unreliable protocols are connection-oriented, such as [[Asynchronous Transfer Mode]] and [[Frame Relay]]. In addition, some connectionless protocols, such as [[IEEE 802.11]], are reliable.

Line 61:

AFDX uses frequency ___domain [[Traffic policing (communications)|traffic policing]] or bandwidth allocation, that allows the traffic on each virtual link (VL) to be limited so that the requirements for shared resources can be predicted and [[congestion prevention|congestion prevented]] so it can be proved not to affect the critical data.<ref>AFDX Tutorial, {{cite web |url=http://www.techsat.com/fileadmin/media/pdf/infokiosk/TechSAT_TUT-AFDX-EN.pdf |title=Archived copy |accessdate=2015-02-03 |url-status=dead |archiveurl=https://web.archive.org/web/20150618140031/http://www.techsat.com/fileadmin/media/pdf/infokiosk/TechSAT_TUT-AFDX-EN.pdf |archivedate=2015-06-18 }}</ref> However, the techniques for predicting the resource requirements and proving that congestion is prevented are not part of the AFDX standard.

TTEthernet provides the lowest possible latency in transferring data across such a network by using time-___domain control methods – each time triggered transfer is scheduled at a specific time, so that contention for shared resources is entirely controlled and thus the possibility of congestion is eliminated. The switches in the network enforce this timing to provide tolerance of faults in, and malicious actions on the part of, the other connected equipment. However, "synchronized local clocks are the fundamental prerequisite for time-triggered communication".<ref>Wilfried Steiner and Bruno Dutertre, [http://www.csl.sri.com/users/bruno/publis/fmics2010.pdf ''SMT-Based Formal Verification of a ''TTEthernet'' Synchronization Function''], S. Kowalewski and M. Roveri (Eds.), FMICS 2010, LNCS 6371, pp. 148–163, 2010.</ref> This is because the sources of critical data will have to have the same view of time as the switch, in order that they can transmit at the correct time and the switch will see this as correct. This also requires that the sequence with which a critical transfer is scheduled has to be predictable to both source and switch. This, in turn, will limit the transmission schedule to a highly deterministic one, e.g. the [[cyclic executive]].

However, low latency in transferring data over the bus or network does not necessarily translate into low transport delays between the application processes that source and sink this data. This is especially true where the transfers over the bus or network are cyclically scheduled (as is commonly the case with MIL-STD-1553B and STANAG 3910, and necessarily so with AFDX and TTEthernet) but the application processes are [[wikt:asynchronous|asynchronous]], e.g. [[Preemption (computing)|pre-emptively scheduled]], or only [[Plesiochronous system|plesiosynchronous]] with this schedule. In this case, the maximum delay and jitter will be twice the update rate for the cyclic transfer (transfers wait up to the update interval between release and transmission and again wait up to the update interval between delivery and use).