Draft: draft-ietf-taps-interface

Commentary: This is a remake of as suggested . It moves the WithIPvXMulticastGroup for receiving to the LocalEndpoint and adds the ASM / SSM distinguisher . It does not add TTL support . 
 I got more in - person input from in person in Philly . We might want to include the src addr for SSN into a " WithSSNMulticastGroup " endpoint attribute and make Multicast addresses " special " that way . I guess we do n't want to support racing multicast against non - multicast for now . 
 This will if merged . 
 Overall I think this looks like it should be fine . The things that are not currently clear to me ( might be covered elsewhere already ? I have n't re - reviewed the whole doc ): What if any difference is there between a sender using  .  and RemoteSpecifier . WithIPvXAddress ? Would WithIPvXAddress raise an error if given a group address , or would it use different defaults for the packets , or what exactly ? ( I 'm thinking here of TTL / hoplimit and destination mac address as the 2 examples that come to mind that could have different defaults for these cases . ) how is the default interface determined if not provided explicitly ? ( when joining with an api that allows not specifying the interface , I think sockets use the route to the group address , but I think ssm receive probably should use the route to the source address ) will the listener merge receive data from different source addresses and source ports as packets are received into the same connection object , or will each new source (  , port ) pair result in a new connection , or is there some kind of controller that can pick between these ? Outside of these , I have n't noticed any questions without answers that seem obvious to me . LGTM but I 'd like eyes on this as well . LGTM , one minor nit
Paragraph (version A):
Specifying a multicast group address on a Local Endpoint will
indicate to the Transport Services system that the resulting
connection will be used to receive multicast messages.  The Remote
Endpoint can be used to filter incoming multicast from specific
senders.  Such a Preconnection will only support calling Listen(),
not Initiate().  Calling Listen() will cause the Transport Services
system to register for receiving multicast, such as issuing an IGMP
join RFC3376 or using MLD for IPV6 RFC4604.  Any Connections that are
accepted from this Listener are receive-only.
Paragraph (version A):
Similarly, specifying a multicast group address on the Remote
Endpoint will indicate that the resulting connection will be used to
send multicast messages, and that the Preconnection will support
Initiate() but not Listen().  Any Connections created this way are
send-only.
Paragraph (version A):
A Rendezvous() call on Preconnections containing group addresses
results in an EstablishmentError as described in rendezvous.
Paragraph (version B):
To use multicast, a Preconnection is first created with the Local/
Remote Endpoint specifying the any-source multicast (ASM) or source-
specific multicast (SSM) multicast group and destination port number.
Paragraph (version B):
Calling Initiate() on that Preconnection creates a Connection that
can be used to send messages to the multicast group.  The Connection
object that is created will support Send() but not Receive().  Any
Connections created this way are send-only, and do not join the
multicast group.  The resulting Connection will have a Local Endpoint
indicating the local interface to which the connection is bound and a
Remote Endpoint indicating the multicast group.
Paragraph (version B):
Calling Listen() on a Preconnection with a multicast group specified
on the Remote Endpoint will join the multicast group to receive
messages.  This Listener will create one Connection for each Remote
Endpoint sending to the group, with the Local Endpoint set to the
group address.  The set of Connection objects created forms a
Connection Group.  The receiving interface can be restricted by
passing it as part of the LocalSpecifier or queried through the
MessagContext on the messages received (see msg-ctx for further
details).
Paragraph (version B):
Calling Rendezvous() on a Preconnection with an any-source multicast
group address as the Remote Endpoint will join the multicast group,
and also indicates that the resulting connection can be used to send
messages to the multicast group.  The Rendezvous() call will return
both a Connection that can be used to send to the group, that acts
the same as a connection returned by calling Initiate() with a
multicast Remote Endpoint, and a Listener that acts as if Listen()
had been called with a multicast Remote Endpoint.  Calling
Rendezvous() on a Preconnection with a source-specific multicast
group address as the Local Endpoint results in an EstablishmentError.
Paragraph (version A):
One common pattern for multicast is to both send and receive
multicast.  For such cases, an application can set up both a Listener
and a Connection.  The Listener is only used to accept Connections
that receive inbound multicast.  The initiated Connection is only
used to send multicast.
Paragraph (version B):
The following examples show how multicast groups can be used.
Paragraph (version A):
When additional information (such as Provisioning Domain (PvD)
information RFC7556) is available about the networks over which an
endpoint can operate, this can inform the selection between alternate
network paths.
Path information can include network segment PMTU, set of supported
DSCPs, expected usage, cost, etc.  The usage of this information by
the Transport Services System is generally independent of the
specific mechanism/protocol used to receive the information (e.g.
zero-conf, DHCP, or IPv6 RA).
Paragraph (version B):
When additional information (such as Provisioning Domain (PvD)
information RFC7556) is available about the networks over which an
endpoint can operate, this can inform the selection between alternate
network paths.  Path information can include network segment PMTU,
set of supported DSCPs, expected usage, cost, etc.  The usage of this
information by the Transport Services System is generally independent
of the specific mechanism/protocol used to receive the information
(e.g. zero-conf, DHCP, or IPv6 RA).
Paragraph (version B):
To aid readability, implementations MAY provide additional
convenience functions to simplify use of Selection Properties: see
preference-conv for examples.  In addition, implementations MAY
provide a mechanism to create TransportProperties objects that are
preconfigured for common use cases, as outlined in property-profiles.
Paragraph (version B):
connection-props provides a list of Connection Properties, while
Selection Properties are listed in the subsections below.  Selection
Properties are only considered during establishment, and can not be
changed after a Connection is established.  After a Connection is
established, Selection Properties can only be read to check the
properties used by the Connection.  Upon reading, the Preference type
of a Selection Property changes into Boolean, where "true" means that
the selected Protocol Stack supports the feature or uses the path
associated with the Selection Property, and "false" means that the
Protocol Stack does not support the feature or use the path.
Implementations of Transport Services systems may alternatively use
the two Preference values "Require" and "Prohibit" to represent
"true" and "false", respectively.
Paragraph (version B):
The optional "connectionProperties" parameter allows passing
Transport Properties that control the behavior of the underlying
stream or connection to be created, e.g., protocol-specific
properties to request specific stream IDs for SCTP or QUIC.
Paragraph (version B):
A Transport Services API can request a protocol that supports sending
keep alive packets keep-alive.  If this property is Numeric, it
specifies the maximum length of time an idle connection (one for
which no transport packets have been sent) should wait before the
Local Endpoint sends a keep-alive packet to the Remote Endpoint.
Adjusting this Property will only take effect when the underlying
stack supports sending keep-alive packets.  Guidance on setting this
value for connection-less transports is provided in RFC8085.  A value
greater than the connection timeout (conn-timeout) or the enumerated
value "Disabled" will disable the sending of keep-alive packets.
Paragraph (version B):
Numeric values of this property specify an upper-bound rate that a
transfer is not expected to exceed (even if flow control and
congestion control allow higher rates), and/or a lower-bound rate
below which the application does not deem it will be useful.  These
are specified in bits per second.  The enumerated value "Unlimited"
indicates that no bound is specified.
Paragraph (version B):
If this property is Numeric, it controls the number of Connections
that can be accepted from a peer as new members of the Connection's
group.  Similar to SetNewConnectionLimit(), this limits the number of
ConnectionReceived Events that will occur, but constrained to the
group of the Connection associated with this property.  For a multi-
streaming transport, this limits the number of allowed streams.
Paragraph (version B):
This property represents the maximum Message size that an application
can send.  It is specified as the number of bytes.
Paragraph (version B):
This property represents the maximum Message size that an application
can receive.  It specified as the number of bytes.
Paragraph (version B):
This only takes effect when the transport uses a network layer that
supports this functionality.  When it does take effect, setting this
property to true will cause the sender to avoid network-layer source
fragmentation.  When using IPv4, this will result in the Don't
Fragment bit being set in the IP header.
Paragraph (version B):
When set to true, this property requests the transport layer to not
provide segmentation of messages larger than the maximum size
permitted by the network layer, and also to avoid network-layer
source fragmentation of messages.  When running over IPv4, setting
this property to true will result in a sending endpount setting the
Don't Fragment bit in the IPv4 header of packets generated by the
transport layer.
Paragraph (version B):
An attempt to send a message that results in a size greater than the
transport's current estimate of its maximum packet size
("singularTransmissionMsgMaxLen") will result in a "SendError".  This
only takes effect when the transport and network layer support this
functionality.
Paragraph (version B):
Of course any communication over a network reveals usage
characteristics, because all packets, as well as their timing and
size, are part of the network-visible wire image RFC8546.  However,
the selection of a protocol and its configuration also impacts which
information is visible, potentially in clear text, and which other
entities can access it.  In most cases, information provided for
protocol and path selection should not directly translate to
information that can be observed by network devices on the path.
However, there might be specific configuration information that is
intended for path exposure, e.g., a DiffServ codepoint setting, that
is either provided directly by the application or indirectly
configured for a traffic profile.