Draft: draft-ietf-taps-interface

Commentary: These are all my self - assigned issues , where I think the discussion has converged . , , , , , , , 
 - I wonder if a good way ahead would be to merge this as - is , but remove from the " closes " list ? As being discussed in , the right way ahead for the Listen / cloning problem may be a bigger change , which I 'd rather do in a separate PR . 
 Yes , that sounds like a good way to move forward . 
 To slightly more structure the long list of connection properties in the API doc we could at least have an own subsection for read - only properties ... 
 Section 11.1.4 in the API doc on Timeout for Aborting Connection says : " The special value -1 means that this timeout is not scheduled to happen . " Not sure what this is supposed to say . Does n't every protocol have some kind of timeout after which it will give up ? 
 UDP does n't ... perhaps we should be explicit about this though , to avoid confusion , and add : ( this can , e.g. , be a valid choice in case of UDP ) 
 A bunch or questions on ECN : Do we want a transport property that indicates that ECN should be requested during the handshake if supported by the selected protocol ? Or is the assumption that this is rather a system configuration ? Do we need to say this somewhere ? Further I do n't think that having ECN markings as a ( receive ) message property is correct as a message may consist out of multiple packets / datagrams and there could also be packets that do n't contain message data at all . I mean the mapping is straight forward for UDP but I guess one could also use QUIC as a datagram only service ? And can one use message framers with UDP ? Maybe we should have this a protocol specific property for UDP only ? Or we could allow to register events that indicate reception of certain ECN - marked segments ? Or we just maintain counters that could be polled by the application ... ? 
 I think it 's not of concern to the application unless the application has to do congestion control - as in UDP 's case - which is probably why UDP is the only transport that exposes ECN ..  Well , in UDP - the only case we have , so far , AFAIK - it is associated with a packet , which becomes a Message . As you say , the mapping is straightforward for UDP - but e.g. QUIC as a datagram only service should n't expose ECN because QUIC is congestion controlled . We could do that , if you think that makes it cleaner ? The logic : " associated with a singular Message whenever it 's exposed , because the transport does n't do congestion control " seems quite general to me . But I 'd be fine with making it UDP specific anyway . 
 To me it is datagram specific to connection - less protocols . Really this means UDP in this context . Transports that are connection - oriented can have the functionality to check for ECN , enable this , detect and respond to marking and appropriate machinery to decide how to fallback . To me , all of this is a system decision not application . It does n't appear in the API except for UDP - based services . 
 Should we have this as protocol specific property then ? 
 Good idea ! 
 " Name : : retransmit - notify This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold . The default is to  this option . " I guess we then also need an option to set this threshold ? Or we make this option of type  and say 0 is ignore . 
 If you say " yes " to this Selection Property , then ( depending on the outcome of racing ) , the Generic Connection Property retransmit - notify - threshold ( sec . 11.1.1 . ) will be the one to use . I guess this just needs a reference to this section . 
 Ah , thanks , still reviewing ... yes all we need is a reference ! 
 Is this useful ? - Lower layers may duplicate , protocols may retransmit for various reasons ( apart from loss - timer issues , robustness concerns , etc . So what utility does this bring ? If we need it then we should explain and define a threshold . Can we live without these being a specified part of the API ? 
 It 's a minset thing . So , backtracking : Appendix : this maps to " Notification of Excessive Retransmissions ( early warning below abortion threshold)"Minset A.1 points back at ERROR.TCP in RFC 8303 , and classifies this as : " Optimizing because it is an early warning to the application , informing it of an impending functional event . "In RFC 8303 , it gets clear that ERROR.TCP is about soft errors from ICMP , including at least " ICMP error message arrived and excessive retransmissions " , and there is a pointer to Section 4.2.4.1 of RFC 1122.There , we find : " However , the conditions that are reported asynchronously to the application MUST include ( .. ) Excessive retransmissions ( see 4.2.3.5 ) ( .. ) " . In Section 4.2.3.5 , we have : " Excessive retransmission of the same segment by TCP indicates some failure of the remote host or the Internet path . This failure may be of short or long duration . The following procedure MUST be used to handle excessive retransmissions of data segments [ IP:11 ] : " , followed by text that talks about a configurable threshold for early notification ( in addition to having a higher abortion threshold ) . So : I agree that this may not be super useful - but it 's a case where we have a MUST regarding notifying the application , and a MUST for configuring a threshold . Hence we could n't simply make it a part of the soft error notification , because then would n't get to configure the threshold . As stated above , we currently do have a configurable threshold : the Generic Connection Property retransmit - notify - threshold . 
 I the reference , which was needed as and I agreed above . If someone wants to discuss this even more , shout - before the end of this week . If noone shouts , I 'll close this next week . 
 Adding the reference seems like the correct thing to do . If we were to discuss the usefulness - I have doubts - but we do n't need to have that discussion . 
 Closing now in this case :) 
 Should n't section 5.2.1 to 5.2.9 also specify a type , namely Preference ? 
 I just noticed for Message and Connection Properties we have Type and Default as separate " bullets " for each property . Can we do the same for selection properties ? 
 I agree , we should do this . 
 Currently we define a Preconnection like this : Preconnection : = NewPreconnection(LocalEndpoint , RemoteEndpoint , TransportProperties , SecurityParams ) And then use it in the examples e.g. like this : Preconnection : = NewPreconnection(None , RemoteSpecifier , TransportPreperties , SecurityParameters ) But should we do this instead : Preconnection : = NewPreconnection(LocalEndpoint ? , RemoteEndpoint ? , TransportProperties , SecurityParams ) I know that is also a bit confusing but maybe more inline with the syntax we define . Or we probably need to at least define the keyword " None " ... 
 I think your proposed syntax change makes sense . When we first wrote this , we did n't have optional parameters yet , but now that we do , let 's use them ! 
 In section 4 , we say : " Messages are received asynchronously through event handlers registered by the application . Errors and other notifications also happen asynchronously on the Connection . " This does not explain whether event handlers MUST be registered for all types of events ( I guess not ? ) , and what happens when no event handler is registered ( I guess some reasonable default behavior - but should n't we be explicit about this ? ) . 
 I definitely think they should not be required for all events ( especially errors ) . I would assume that an event only gets thrown if an event handler is registered . 
 I think it is important to allow certain events not to be handled by applications . That 's one goal that I 've had in Network.framework . A minimal application not catch all edge cases , but it can certainly ignore events it does n't do anything special with . For example , an application can not register any handler for a connection becoming ready , if it instead just sends , and waits for a send to succeed or fail . 
 If there are certain types of event handlers that MUST be registered , then we need to be explicit about that . The others are , presumably , SHOULD register a handler ? 
 I very much agree with folks that we should not require all event handlers to be registered ! However , the text currently just is n't explicit about these things at all . Indeed : if something MUST be registered , the text should say so . But also , if an event handler is not registered for some events , then the text should explain that this is ok , and then ,  will happen . 
 Absolutely agree . Require the application to register all event handlers would make the API highly unflexible ! Could it be an idea to require certain event handlers to be passed with key API calls like ? It does n't make much sense to start listening without a handler for incoming connections . 
 I see no event in the API an application MUST subscribe to , but there are a lots it should . What might need mentioning is that some events may have implementation - specific default handlers that do some thing ( e.g. , exit the application ) and the application should not assume ignore everything is always safe .
Paragraph (version A):
Once a Connection is established, data can be sent and received on it
in the form of Messages.  The interface supports the preservation of
message boundaries both via explicit Protocol Stack support, and via
application support through a Message Framer which finds message
boundaries in a stream.  Messages are received asynchronously through
event handlers registered by the application.  Errors and other
notifications also happen asynchronously on the Connection.
Paragraph (version B):
Once a Connection is established, data can be sent and received on it
in the form of Messages.  The interface supports the preservation of
message boundaries both via explicit Protocol Stack support, and via
application support through a Message Framer which finds message
boundaries in a stream.  Messages are received asynchronously through
event handlers registered by the application.  Errors and other
notifications also happen asynchronously on the Connection.  It is
not necessary for an application to handle all events; some events
may have implementation-specific default handlers.  The application
should not assume that ignoring events (e.g. errors) is always safe.
Paragraph (version A):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.  The default is to Require
Reliable Data Transfer.
Paragraph (version A):
This property specifies whether the application needs or prefers to
use a transport protocol that preserves message boundaries.  The
default is to Prefer Preservation of Message Boundaries.
Paragraph (version A):
This property specifies whether an application considers it useful to
indicate its reliability requirements on a per-Message basis.  This
property applies to Connections and Connection Groups.  The default
is to Ignore this option.
Paragraph (version A):
This property specifies whether the application wishes to use a
transport protocol that can ensure that data is received by the
application on the other end in the same order as it was sent.  The
default is to Require Preservation of data ordering.
Paragraph (version A):
This property specifies whether an application would like to supply a
Message to the transport protocol before Connection establishment,
which will then be reliably transferred to the other side before or
during Connection establishment, potentially multiple times (i.e.,
multiple copies of the message data may be passed to the Remote
Endpoint).  See also msg-idempotent.  The default is to Ignore this
option.  Note that disabling this property has no effect for
protocols that are not connection-oriented and do not protect against
duplicated messages, e.g., UDP.
Paragraph (version A):
This property specifies that the application would prefer multiple
Connections within a Connection Group to be provided by streams of a
single underlying transport connection where possible.  The default
is to Prefer this option.
Paragraph (version A):
This property specifies whether the application desires protection
against corruption for all data transmitted on this Connection.
Disabling this property may enable to control checksum coverage later
(see msg-checksum).  The default is to Require this option.
Paragraph (version A):
This property specifies whether the application desires protection
against corruption for all data received on this Connection.  The
default is to Require this option.
Paragraph (version B):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.
Paragraph (version B):
This property specifies whether the application needs or prefers to
use a transport protocol that preserves message boundaries.
Paragraph (version B):
This property specifies whether an application considers it useful to
indicate its reliability requirements on a per-Message basis.  This
property applies to Connections and Connection Groups.
Paragraph (version B):
This property specifies whether the application wishes to use a
transport protocol that can ensure that data is received by the
application on the other end in the same order as it was sent.
Paragraph (version B):
This property specifies whether an application would like to supply a
Message to the transport protocol before Connection establishment,
which will then be reliably transferred to the other side before or
during Connection establishment, potentially multiple times (i.e.,
multiple copies of the message data may be passed to the Remote
Endpoint).  See also msg-idempotent.  Note that disabling this
property has no effect for protocols that are not connection-oriented
and do not protect against duplicated messages, e.g., UDP.
Paragraph (version B):
This property specifies that the application would prefer multiple
Connections within a Connection Group to be provided by streams of a
single underlying transport connection where possible.
Paragraph (version B):
This property specifies whether the application desires protection
against corruption for all data transmitted on this Connection.
Disabling this property may enable to control checksum coverage later
(see msg-checksum).
Paragraph (version B):
This property specifies whether the application desires protection
against corruption for all data received on this Connection.
Paragraph (version A):
The default is to not set a preference for any interface.
Paragraph (version A):
The default is to not set a preference for any PvD.
Paragraph (version A):
The default is to prefer the use of stable local addresses for
Listeners and Rendezvous Connections, and to prefer the use of
temporary addresses for other Connections.
Paragraph (version A):
The default is Disabled.  The other enumeration values are all
interpreted as preferences.
Paragraph (version B):
Enumeration values other than "Disabled" are interpreted as
preferences.
Paragraph (version A):
The default is bidirectional.  Since unidirectional communication can
be supported by transports offering bidirectional communication,
specifying unidirectional communication may cause a transport stack
that supports bidirectional communication to be selected.
Paragraph (version A):
This property specifies whether an application considers it useful to
be informed in case sent data was retransmitted more often than a
certain threshold.  The default is to Ignore this option.
Paragraph (version A):
This property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  When set to true, received ICMP errors
will be available as SoftErrors, see soft-errors.  Note that even if
a protocol supporting this property is selected, not all ICMP errors
will necessarily be delivered, so applications cannot rely on
receiving them.  By default this option is set to false.
Paragraph (version B):
Since unidirectional communication can be supported by transports
offering bidirectional communication, specifying unidirectional
communication may cause a transport stack that supports bidirectional
communication to be selected.
Paragraph (version B):
This property specifies whether an application considers it useful to
be informed in case sent data was retransmitted more often than a
certain threshold (see conn-excss-retransmit for configuration of
this threshold).
Paragraph (version B):
This property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  When set to true, received ICMP errors
will be available as SoftErrors, see soft-errors.  Note that even if
a protocol supporting this property is selected, not all ICMP errors
will necessarily be delivered, so applications cannot rely on
receiving them.
Paragraph (version A):
Changing one of the Connection Properties on one Connection in the
group changes it for all others.  Message Properties, however, are
not entangled.  For example, changing "Timeout for aborting
Connection" (see conn-timeout) on one Connection in a group will
automatically change this Connection Property for all Connections in
the group in the same way.  However, changing "Lifetime" (see msg-
lifetime) of a Message will only affect a single Message on a single
Connection, entangled or not.
Paragraph (version B):
ListenClone() creates a Listener that listens on the same
LocalEndpoint as the one the cloned Connection is using.  Any new
Connection received by this Listener will be entangled with the
cloned Connection.  Changing one of the Connection Properties on one
Connection in the group changes it for all others.  Message
Properties, however, are not entangled.  For example, changing
"Timeout for aborting Connection" (see conn-timeout) on one
Connection in a group will automatically change this Connection
Property for all Connections in the group in the same way.  However,
changing "Lifetime" (see msg-lifetime) of a Message will only affect
a single Message on a single Connection, entangled or not.
Paragraph (version A):
Note that calling Clone() may result in on-the-wire signaling, e.g.,
to open a new connection, depending on the underlying Protocol Stack.
Paragraph (version B):
Note that calling Clone() may result in on-the-wire signaling, e.g.,
to open a new connection, depending on the underlying Protocol Stack.
When Clone() leads to multiple connections being opened instead of
multi-streaming, the transport system will ensure consistency of
Connection Properties by uniformly applying them to all underlying
connections in a group.  Even in such a case, there are possibilities
for a transport system to implement prioritization within a
Connection Group TCP-COUPLING RFC8699.
Paragraph (version A):
When available, Message metadata carries the value of the Explicit
Congestion Notification (ECN) field.  This information can be used
for logging and debugging purposes, and for building applications
which need access to information about the transport internals for
their own operation.
Paragraph (version B):
When available, Message metadata carries the value of the Explicit
Congestion Notification (ECN) field.  This information can be used
for logging and debugging purposes, and for building applications
which need access to information about the transport internals for
their own operation.  This property is specific to UDP and UDP-Lite
because these protocols do not implement congestion control, and
hence expose this functionality to the application.
Paragraph (version A):
This property specifies how long to wait before deciding that a
Connection has failed when trying to reliably deliver data to the
destination.  Adjusting this Property will only take effect when the
underlying stack supports reliability.  The special value -1 means
that this timeout is not scheduled to happen.
Paragraph (version B):
This property specifies how long to wait before deciding that a
Connection has failed when trying to reliably deliver data to the
destination.  Adjusting this Property will only take effect when the
underlying stack supports reliability.  The special value -1 means
that this timeout is not scheduled to happen.  This can be a valid
choice with unreliable data transfer (e.g., when UDP is the
underlying transport protocol).
Paragraph (version A):
This property represents the maximum Message size that can be sent.
Paragraph (version B):
The following generic Connection Properties are read-only, i.e. they
cannot be changed by an application.
Paragraph (version B):
This property represents the maximum Message size that can be sent
using a send operation.