Flow and Retransmission Control Protocol - Revision history

Dimitri at 10:05, 28 October 2023

2023-10-28T10:05:56Z

← Older revision		Revision as of 10:05, 28 October 2023
Line 1:		Line 1:
	The Flow and Retransmission Control Protocol is, together with [[Ouroboros Data Transfer Protocol]] and [[Ouroboros Flow ~~Allocator~~ Protocol]] one of the three core protocols in [[Ouroboros]].		The Flow and Retransmission Control Protocol is, together with [[Ouroboros Data Transfer Protocol]] and [[Ouroboros Flow Allocation Protocol]] one of the three core protocols in [[Ouroboros]].

	== Header ==		== Header ==

Dimitri at 10:05, 28 October 2023

2023-10-28T10:05:18Z

← Older revision		Revision as of 10:05, 28 October 2023
Line 1:		Line 1:
	The Flow and Retransmission Control Protocol is, together with [[Ouroboros Data Transfer Protocol]] and [[Flow Allocator Protocol]] one of the three core protocols in [[Ouroboros]].		The Flow and Retransmission Control Protocol is, together with [[Ouroboros Data Transfer Protocol]] and [[Ouroboros Flow Allocator Protocol]] one of the three core protocols in [[Ouroboros]].

	== Header ==		== Header ==

Dimitri: /* Reliable delivery */

2023-10-28T10:04:41Z

Reliable delivery

← Older revision		Revision as of 10:04, 28 October 2023
Line 56:		Line 56:
	The reliable delivery has to deal with lost packets, duplicates,etc. Automated-repeat request handles this: if a packet is not acknowledged within a certain time-frame, it is retransmitted by the sender.		The reliable delivery has to deal with lost packets, duplicates,etc. Automated-repeat request handles this: if a packet is not acknowledged within a certain time-frame, it is retransmitted by the sender.

	For reliable transmission in the presence of lost packets to work, three timers need to be bounded. These timers define a “data run”. The state is uni-directional, so for bi-directional communication, each side has a sender record and a receiver record.		For reliable transmission in the presence of lost packets to work, three timers need to be bounded<ref>[https://doi.org/10.1016/0376-5075(81)90031-3 Timer-based mechanisms in reliable transport protocol connection management]</ref>. These timers define a “data run”. The state is uni-directional, so for bi-directional communication, each side has a sender record and a receiver record.

	# '''MPL''': The maximum packet lifetime. This is bound by the network below, using the TTL mechanism. It is approximate with the probability of a packet still arriving after MPL close to zero.		# '''MPL''': The maximum packet lifetime. This is bound by the network below, using the TTL mechanism. It is approximate with the probability of a packet still arriving after MPL close to zero.

Dimitri at 10:03, 28 October 2023

2023-10-28T10:03:39Z

← Older revision		Revision as of 10:03, 28 October 2023
Line 42:		Line 42:
	= Operation =		= Operation =

	The operation of FRCP is based on the operation of the Delta-t protocol<ref>[https://www.osti.gov/biblio/5542785 Delta-t protocol specification: working draft</ref>, which is a timer-based protocol with functionality equivalent to the ARQ and flow control functionalities in TCP. FRCP is configurable with a number of functions:		The operation of FRCP is based on the operation of the Delta-t protocol<ref>[https://www.osti.gov/biblio/5542785 Delta-t protocol specification: working draft]</ref>, which is a timer-based protocol with functionality equivalent to the ARQ and flow control functionalities in TCP. FRCP is configurable with a number of functions:

	== In-order delivery ==		== In-order delivery ==

Dimitri: /* Implementation */

2023-10-24T18:16:29Z

Implementation

← Older revision		Revision as of 18:16, 24 October 2023
Line 85:		Line 85:
	* In-order delivery: Implemented		* In-order delivery: Implemented
	* Duplicate detection: Implemented		* Duplicate detection: Implemented
	* ARQ: Proof-of-concept implemented		* ARQ: Proof-of-concept implemented, timerwheel needs to be moved from application to shared memory so IRMd can schedule retransmissions
	* Flow control: Proof-of-concept implemented		* Flow control: Proof-of-concept implemented
	* Fragmentation: not yet implemented		* Fragmentation: not yet implemented

	= References =		= References =

Dimitri: /* Discussion */

2023-10-24T18:15:43Z

Discussion

← Older revision		Revision as of 18:15, 24 October 2023
Line 79:		Line 79:

	The last mechanism in FRCP is fragmentation. Messages that are too large to be transmitted on the supporting flow are split up in different packets, called “fragments”. These are marked with two bits. First fragment (FFGM), and More fragments (MFGM). A message that fits in a single packet has the FFGM \| MFGM bits set to “10”. If a message is fragmented, it will have a sequence of packets with the bits set to “11” for the first fragment, “01” for intermediate fragments and “00” for the last fragment. Single-bit fragmentation (e.g. only a MFGM bit) is more minimalistic , but it discards two consecutive messages if the last fragment of the first message is lost. This is just being ‘nice’ at little cost.		The last mechanism in FRCP is fragmentation. Messages that are too large to be transmitted on the supporting flow are split up in different packets, called “fragments”. These are marked with two bits. First fragment (FFGM), and More fragments (MFGM). A message that fits in a single packet has the FFGM \| MFGM bits set to “10”. If a message is fragmented, it will have a sequence of packets with the bits set to “11” for the first fragment, “01” for intermediate fragments and “00” for the last fragment. Single-bit fragmentation (e.g. only a MFGM bit) is more minimalistic , but it discards two consecutive messages if the last fragment of the first message is lost. This is just being ‘nice’ at little cost.

	~~= Discussion =~~

	Ouroboros has this mechanism implemented in the "application", not in “the network”. If a packet is acknowledged, it is received by the remote program, not possibly waiting in some buffer still to be delivered. If an application crashes, it means all associated state at that endpoint is gone and a new higher-level flow will need to be established. If a program requests encryption, the entire FRCP header is encrypted. This is probably the best course of action to protect against replay attacks or other attacks based on guessing sequence numbers. Note that the size of the sequence number space should be at least (2MPL + R + A) * T, where T is the number of sequence numbers generated in a certain unit of time.

	The requirement that the connection needs to timeout before reuse seems to imply that a flow_dealloc() command may need to wait for (at most) 3MPL + R + A. This would be really annoying in a program, so we send the remaining waiting time to the IRMd/IPCP, so the flow deallocation at the network side will be deferred and the EID will only be released when safe. The flow_dealloc() call at the sender side can exit immediately after all packets are ack’d (or R timed out). TCP has a similar waiting period (TIME_WAIT), which is one of the reasons for the SO_REUSEADDR and SO_LINGER socket options, which disregard these timeouts with some risk. Ouroboros has a number of advantages (and at least one disadvantage) here. The first advantage is that EIDs are all ephemeral, so one being blocked for some time by the IRMd is never a problem (the connection is not tied to address:port, so it can’t block a future connection). The second advantage is that the EID space should be large for security reasons (see above), and should be chosen at random, so reuse of an EID within 3MPL + A + R is unlikely. The disadvantage is the waiting time on exit of the sending program. Since that state is in the Ouroboros application, the sender application has to either wait for the outcome of the connection (and be informed whether all data was sent successfully or not) or the remaining unsent/unacknowledged packets on exit() are lost. The default for TCP sockets is to linger on exit() of the program, where the socket keeps trying to finish packets in the sending buffer of the connection.

	= Implementation =		= Implementation =

Dimitri at 08:50, 24 October 2023

2023-10-24T08:50:32Z

← Older revision		Revision as of 08:50, 24 October 2023
Line 1:		Line 1:
	~~{{Under construction}}~~

	The Flow and Retransmission Control Protocol is, together with [[Ouroboros Data Transfer Protocol]] and [[Flow Allocator Protocol]] one of the three core protocols in [[Ouroboros]].		The Flow and Retransmission Control Protocol is, together with [[Ouroboros Data Transfer Protocol]] and [[Flow Allocator Protocol]] one of the three core protocols in [[Ouroboros]].

Dimitri: /* Reliable delivery */

2023-10-24T08:49:18Z

Reliable delivery

← Older revision		Revision as of 08:49, 24 October 2023
Line 64:		Line 64:
	# '''A''': The maximum time a receiver will wait before acknowledging a given sequence number for the first time.		# '''A''': The maximum time a receiver will wait before acknowledging a given sequence number for the first time.

	It’s not so important when to exactly retransmit a packet, as long as there are no retransmissions beyond the R timer. Ouroboros – like TCP – estimates average round-trip time (sRTT) and its deviation based on ACKs. The retranmission timeout (RTO) is set as the sRTT + 2 dev, and packets are retransmitted after RTO expires, with exponential back-off. The sRTT is measured with microsecond ~~accuracy2~~ and is the actual response time of the server application.		It’s not so important when to exactly retransmit a packet, as long as there are no retransmissions beyond the R timer. Ouroboros – like TCP – estimates average round-trip time (sRTT) and its deviation based on ACKs. The retranmission timeout (RTO) is set as the sRTT + 2 dev, and packets are retransmitted after RTO expires, with exponential back-off. The sRTT is measured with microsecond accuracy and is the actual response time of the server application.

	If the receiver doesn’t hear from the sender for 2MPL + R + A, it may discard its state. If at this point there are packets received beyond the LWE at the receiver, the communication has failed in an unrecoverable way and an error should be returned. From this point, only packets with DRF will be accepted and they will create a new receiver state.		If the receiver doesn’t hear from the sender for 2MPL + R + A, it may discard its state. If at this point there are packets received beyond the LWE at the receiver, the communication has failed in an unrecoverable way and an error should be returned. From this point, only packets with DRF will be accepted and they will create a new receiver state.

Dimitri: /* Fragmentation */

2023-10-24T08:48:44Z

Fragmentation

← Older revision		Revision as of 08:48, 24 October 2023
Line 80:		Line 80:
	== Fragmentation ==		== Fragmentation ==

	The last mechanism in FRCP is fragmentation. Messages that are too large to be transmitted on the supporting flow are split up in different packets, called ~~“fragments”3~~. These are marked with two bits. First fragment (FFGM), and More fragments (MFGM). A message that fits in a single packet has the FFGM \| MFGM bits set to “10”. If a message is fragmented, it will have a sequence of packets with the bits set to “11” for the first fragment, “01” for intermediate fragments and “00” for the last fragment. Single-bit fragmentation (e.g. only a MFGM bit) is more minimalistic , but it discards two consecutive messages if the last fragment of the first message is lost. This is just being ‘nice’ at little cost.		The last mechanism in FRCP is fragmentation. Messages that are too large to be transmitted on the supporting flow are split up in different packets, called “fragments”. These are marked with two bits. First fragment (FFGM), and More fragments (MFGM). A message that fits in a single packet has the FFGM \| MFGM bits set to “10”. If a message is fragmented, it will have a sequence of packets with the bits set to “11” for the first fragment, “01” for intermediate fragments and “00” for the last fragment. Single-bit fragmentation (e.g. only a MFGM bit) is more minimalistic , but it discards two consecutive messages if the last fragment of the first message is lost. This is just being ‘nice’ at little cost.

	= Discussion =		= Discussion =

Dimitri at 08:48, 24 October 2023

2023-10-24T08:48:04Z

← Older revision		Revision as of 08:48, 24 October 2023
Line 88:		Line 88:
	The requirement that the connection needs to timeout before reuse seems to imply that a flow_dealloc() command may need to wait for (at most) 3MPL + R + A. This would be really annoying in a program, so we send the remaining waiting time to the IRMd/IPCP, so the flow deallocation at the network side will be deferred and the EID will only be released when safe. The flow_dealloc() call at the sender side can exit immediately after all packets are ack’d (or R timed out). TCP has a similar waiting period (TIME_WAIT), which is one of the reasons for the SO_REUSEADDR and SO_LINGER socket options, which disregard these timeouts with some risk. Ouroboros has a number of advantages (and at least one disadvantage) here. The first advantage is that EIDs are all ephemeral, so one being blocked for some time by the IRMd is never a problem (the connection is not tied to address:port, so it can’t block a future connection). The second advantage is that the EID space should be large for security reasons (see above), and should be chosen at random, so reuse of an EID within 3MPL + A + R is unlikely. The disadvantage is the waiting time on exit of the sending program. Since that state is in the Ouroboros application, the sender application has to either wait for the outcome of the connection (and be informed whether all data was sent successfully or not) or the remaining unsent/unacknowledged packets on exit() are lost. The default for TCP sockets is to linger on exit() of the program, where the socket keeps trying to finish packets in the sending buffer of the connection.		The requirement that the connection needs to timeout before reuse seems to imply that a flow_dealloc() command may need to wait for (at most) 3MPL + R + A. This would be really annoying in a program, so we send the remaining waiting time to the IRMd/IPCP, so the flow deallocation at the network side will be deferred and the EID will only be released when safe. The flow_dealloc() call at the sender side can exit immediately after all packets are ack’d (or R timed out). TCP has a similar waiting period (TIME_WAIT), which is one of the reasons for the SO_REUSEADDR and SO_LINGER socket options, which disregard these timeouts with some risk. Ouroboros has a number of advantages (and at least one disadvantage) here. The first advantage is that EIDs are all ephemeral, so one being blocked for some time by the IRMd is never a problem (the connection is not tied to address:port, so it can’t block a future connection). The second advantage is that the EID space should be large for security reasons (see above), and should be chosen at random, so reuse of an EID within 3MPL + A + R is unlikely. The disadvantage is the waiting time on exit of the sending program. Since that state is in the Ouroboros application, the sender application has to either wait for the outcome of the connection (and be informed whether all data was sent successfully or not) or the remaining unsent/unacknowledged packets on exit() are lost. The default for TCP sockets is to linger on exit() of the program, where the socket keeps trying to finish packets in the sending buffer of the connection.

	== Implementation ==		= Implementation =

	The implementation of this protocol is part of the application library.		The implementation of this protocol is part of the application library.
Line 97:		Line 97:
	* Fragmentation: not yet implemented		* Fragmentation: not yet implemented

	== References ==		= References =