Ouroboros Data Transfer Protocol - Revision history

Dimitri: /* EID */

2023-10-28T10:29:42Z

EID

← Older revision		Revision as of 10:29, 28 October 2023
Line 52:		Line 52:
	The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen locally by each endpoint IPCP during flow allocation.		The width of this field is configurable, but for security, it should be reasonably long to avoid an attacker guessing valid EID values (the figure shows 64 bits, which is the value used in the prototype). For efficiency, it should be easy to map and EID to a flow descriptor at the endpoints. The value of this field is chosen locally by each endpoint IPCP during flow allocation.

	While Ouroboros does not have well-known EIDs, it does have a notion of ''reserved EID''s for functions that are ''internal'' to an N-layer, such as the [[Flow Allocator \| flow allocator]] and the [[directory]]. These EIDs ~~are~~ unique for the layer and can be communicated during Enrollment.		While Ouroboros does not have well-known EIDs, it does have a notion of ''reserved EID''s for functions that are ''internal'' to an N-layer, such as the [[Flow Allocator \| flow allocator]] and the [[directory]]. These EIDs should not be fixed, unique for the layer and can be communicated during Enrollment.

	==== ECN ====		==== ECN ====

Dimitri: /* Notable fields not present in ODTP */

2023-10-28T10:27:45Z

Notable fields not present in ODTP

← Older revision		Revision as of 10:27, 28 October 2023
Line 72:		Line 72:

	The edge case where an application needs to send a single packet to a destination, or very infrequently, can be covered by piggybacking data on the first flow allocation message.		The edge case where an application needs to send a single packet to a destination, or very infrequently, can be covered by piggybacking data on the first flow allocation message.

			==== Protocol/Next Header ====
			The protocol (IPv4) / Next Header (IPv6) field identifies the protocol on top of the Internet Protocol, which is a clear layer independence violation. ODTP has an Endpoint Identifier field that combines the Protocol and Port functions, and is (nearly) always 'ephemeral'.

	==== Length ====		==== Length ====

	Not needed, because the syntax of the protocol is ~~set~~ during enrollment.		Not needed, because the syntax of the ODTP network forwarding layer protocol is agreed during enrollment.

	== Implementation ==		== Implementation ==

	The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.		The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.

Dimitri: /* Protocol Header */

2023-10-23T10:59:42Z

Protocol Header

← Older revision		Revision as of 10:59, 23 October 2023
Line 7:		Line 7:
	The field widths are not that important, but an optimized version should take into account memory alignment. The Data Transfer Protocol has 3 fields associated with the Data Transfer Component (the network forwarding layer in the model), and 2 fields associated with the flow allocator (the end-to-end network layer in the model).		The field widths are not that important, but an optimized version should take into account memory alignment. The Data Transfer Protocol has 3 fields associated with the Data Transfer Component (the network forwarding layer in the model), and 2 fields associated with the flow allocator (the end-to-end network layer in the model).

			<syntaxhighlight>
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Line 24:		Line 25:
	. .		. .
	. .		. .
			</syntaxhighlight>

	=== Fields associated with the network forwarding layer ===		=== Fields associated with the network forwarding layer ===

Dimitri: /* Notable fields not present in ODTP */

2023-10-23T10:57:48Z

Notable fields not present in ODTP

← Older revision		Revision as of 10:57, 23 October 2023
Line 73:		Line 73:
	==== Length ====		==== Length ====

	Not needed, because ~~there are no optional fields that apply only to some flows. The~~ syntax of the protocol is set during enrollment.		Not needed, because the syntax of the protocol is set during enrollment.

	== Implementation ==		== Implementation ==

	The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.		The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.

Dimitri: /* Length */

2023-10-23T10:57:12Z

Length

← Older revision		Revision as of 10:57, 23 October 2023
Line 73:		Line 73:
	==== Length ====		==== Length ====

	Not needed, because there are no optional fields that apply only to some flows.		Not needed, because there are no optional fields that apply only to some flows. The syntax of the protocol is set during enrollment.

	== Implementation ==		== Implementation ==

	The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.		The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.

Dimitri at 10:54, 23 October 2023

2023-10-23T10:54:45Z

← Older revision		Revision as of 10:54, 23 October 2023
Line 56:		Line 56:
	This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).		This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

	=== Notable fields ~~associated with ''network protocol'' that are~~ not present in ODTP ===		=== Notable fields not present in ODTP ===

	==== Version ====		==== Version ====

Dimitri at 10:54, 23 October 2023

2023-10-23T10:54:11Z

← Older revision		Revision as of 10:54, 23 October 2023
Line 25:		Line 25:
	. .		. .

	== Fields associated with the network forwarding layer ==		=== Fields associated with the network forwarding layer ===

	=== Destination address ===		==== Destination address ====

	This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.		This specifies the address to forward the packet to. The width of this field is configurable based on various preferences and the size of the envisioned network. The Ouroboros default is 64 bits.

	=== Time-to-Live ===		==== Time-to-Live ====

	Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.		Similar to IPv4 (in IPv6 this field is replaced by the Hop Limit), this is decremented at each hop to ensures that packets don’t get forwarded forever in the network, for instance due to (transient) loops in the forwarding path. The Ouroboros default for the width is one octet (byte), limiting the Maximum Packet Lifetime in the network to 255 seconds. The initial TTL value for a flow can be based on the maximum delay requested by the application.

	=== QoS ===		==== QoS ====

	Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.		Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

	== Fields associated with the network end-to-end layer ==		=== Fields associated with the network end-to-end layer ===

	=== EID ===		==== EID ====

	The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. This endpoint uniquely identifies an application/service at the destination, so this field is not identical in function to the ''protocol'' or ''next header'' field in IPv4 or IPv6, but rather it more akin to the function of the (ephemeral) ''port'' field in UDP or TCP. Note that		The Endpoint Identifier (EID) field specified the endpoint for which to deliver the packet. This endpoint uniquely identifies an application/service at the destination, so this field is not identical in function to the ''protocol'' or ''next header'' field in IPv4 or IPv6, but rather it more akin to the function of the (ephemeral) ''port'' field in UDP or TCP. Note that
Line 52:		Line 52:
	While Ouroboros does not have well-known EIDs, it does have a notion of ''reserved EID''s for functions that are ''internal'' to an N-layer, such as the [[Flow Allocator \| flow allocator]] and the [[directory]]. These EIDs are unique for the layer and can be communicated during Enrollment.		While Ouroboros does not have well-known EIDs, it does have a notion of ''reserved EID''s for functions that are ''internal'' to an N-layer, such as the [[Flow Allocator \| flow allocator]] and the [[directory]]. These EIDs are unique for the layer and can be communicated during Enrollment.

	=== ECN ===		==== ECN ====

	This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).		This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

	== Notable fields associated with ''network protocol'' that are not present in ODTP ==		=== Notable fields associated with ''network protocol'' that are not present in ODTP ===

	=== Version ===		==== Version ====

	There is no need for a version field in the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is agreed between IPCPs during [[enrollment]].		There is no need for a version field in the ODTP protocol, even if future changes to the fields are made, or other fields are added. The Data Transfer protocol specification is agreed between IPCPs during [[enrollment]].

	=== Source address ===		==== Source address ====

	There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation \| flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. This is motivated by the following observations:		There is no need for a source address in the header. The source address is exchanged during [[Flow Allocation \| flow allocation]], and when sending a packet, the destination can be found in the flow allocator's flow table. This is motivated by the following observations:
Line 71:		Line 71:
	The edge case where an application needs to send a single packet to a destination, or very infrequently, can be covered by piggybacking data on the first flow allocation message.		The edge case where an application needs to send a single packet to a destination, or very infrequently, can be covered by piggybacking data on the first flow allocation message.

	=== Length ===		==== Length ====

	Not needed, because there are no optional fields that apply only to some flows.		Not needed, because there are no optional fields that apply only to some flows.

	~~== Security ==~~

	~~This protocol is secure as there are no unnecessary mutable fields. For comparison with IPv4 or IPv6, all the fields that are protected by IPSec are simply not present in our protocol.~~

	== Implementation ==		== Implementation ==

	The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.		The implementation of this protocol is part of the unicast IPCP, and is complete, pending some optimizations.

Dimitri: /* Notable fields that are present in similar protocols in other architectures, but not present in ODTP */

2023-10-13T11:54:34Z

Notable fields that are present in similar protocols in other architectures, but not present in ODTP

← Older revision		Revision as of 11:54, 13 October 2023
Line 56:		Line 56:
	This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).		This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

	== Notable fields that are ~~present in similar protocols in other architectures, but~~ not present in ODTP ==		== Notable fields associated with ''network protocol'' that are not present in ODTP ==

	=== Version ===		=== Version ===

Dimitri: /* Notable fields that are not present in ODTP */

2023-10-13T11:53:51Z

Notable fields that are not present in ODTP

← Older revision		Revision as of 11:53, 13 October 2023
Line 56:		Line 56:
	This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).		This field specifies Explicit Congestion Notification (ECN), with similar intent as the ECN bits in the Type-of-Service field in IPv4 or Traffic Class field in IPv6. The Ouroboros ECN field is by default one octet wide, and its value can be set to an increasing value as packets are queued deeper and deeper in a congested routers’ forwarding queues. Ouroboros enforces Forward ECN (FECN).

	== Notable fields that are not present in ODTP ==		== Notable fields that are present in similar protocols in other architectures, but not present in ODTP ==

	=== Version ===		=== Version ===

Dimitri: /* Fields associated with the end-to-end network layer */

2023-10-13T11:53:19Z

Fields associated with the end-to-end network layer

← Older revision		Revision as of 11:53, 13 October 2023
Line 39:		Line 39:
	Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.		Ouroboros supports Quality of Service via a number of methods, and this field is used to prioritize scheduling of the packets when forwarding. For instance, if the network gets congested and queues start filling up, higher priority packets (e.g. a voice call) get scheduled more often than lower priority packets (e.g. a file download). By default this field is one octet long.

	== Fields associated with the end-to-end ~~network~~ layer ==		== Fields associated with the network end-to-end layer ==

	=== EID ===		=== EID ===