Draft: draft-ietf-taps-impl

Commentary: Addresses comments from 
 I did not manage to review it all , but I did read much of the ID , and have minor corrections - mainly comments below /such as mobile client/ as /e.g . , a mobile  /Like with derived endpoints/ as /Similar to a derived endpoint/ /Protocol options are checked next in order./ as /Protocol options are next checked in order./ Why s is there no section on immediate - it would be more complete and also the subsection no . would match the list of items in sect 4.4 . Sect : Derived Endpoints /The connection library should order the derived endpoints/ what does /should/ mean here ? - I thought the next stage took an ordered list ( highest preference first ) , so I 'd expect it does order ? and it would seem hugely sensible to put most preferred first , aka RFC8305 . / as a branch which can be attempted independently from other hostnames . Each of these hostnames may also resolve to one or more addresses , thus creating multiple layers of branching./ In above change /which / that/ In above /may also resolve ... thus creating/ ... I can see this /might resolve to one or more addresses , that would create/ ... but I could also read multiple other ways to view the sentence . /connection over either interface . / why 2 ? - should this be : / connection over any interface . / /A single connection may be allowed to use an HTTP - based proxy , a SOCKS - based proxy , or connect directly . / what does /may be allowed to use / actually mean ? is it allowed to use , or if not , what controls whether it is or not ? /that may provide preferable characteristics when available . / could this be : /that , when available , could provide preferable characteristics./ is it /characteristics/ , did the WG previously call these features ? /Implementations that support racing protocols and protocol options should maintain a history of which protocols and protocol options successfully established , on a per - network basis / is it only on a per - network ; could it be also per - endpoint . / since usable DNS results on one network may not necessarily be the same as DNS results on another network due to local network entities , supported address families , or enterprise network configurations . / Personally , I 'd go further than /may not necessarily be/ towards /there are situations when the results will be different/ ? I could be overly sensitive , but did n't like : /has cached the information that SCTP is not available on the path over WiFi,/ can this be : /has current cache information that SCTP is not available on the path over WiFi,/ I wanted to avoid the impression this was something in any way permanent . Sorting branches : / in order of their preference rank/ increasing or decreasing preference ? /Implementations should process properties in the following order : Prohibit , Require , Prefer , Avoid . / the words should process ... seem to chime wrongly to me why would n't they ? can we just remove /should/ or explain what we are saying if that is n't it ? ... there are several " should " words in the rest of the para , and it seems to me that it would be more beautiful had we avoided that word , or explained why there were cases why not ? I got a little muddled with : / While the tree described above is a useful conceptual and architectural model , an implementation does not know what the full tree may become up front , nor will many of the possible branches be used in the common case./ is this clearer as : / The tree described above is a useful conceptual and architectural model . However , an implementation is unable to know the full tree before it is formed and many of the possible branches ultimately might not be commonly used./ / It is useful to process success and failure throughout the tree by child nodes reporting to their parent nodes ( towards the trunk of the tree ) . / Did not parse well to me . /New connection attempts that involve transmitting data on the network should not be started after another leaf node has completed successfully , as the connection as a whole has been established . / the /as/ read poorly to me : /New connection attempts that involve transmitting data on the network ought not to be started after another leaf node has already successfully completed , because the connection as a whole has now been established . / /Similarly , an implementation may choose to hold onto fully established leaf nodes that were not the first to establish for use as part of    , see Section 7.1 , or in future connections./ what does hold on to mean , and /that were not the first to establish for use as part of a  Connection/ was unclear . /In both cases , keeping additional connections is generally not recommended since those attempts were slower to connect and may exhibit less desirable properties./ maybe better as : /In both cases , it is not generally not recommended to keep additional connections , because those attempts were slower to connect and may exhibit less desirable properties./ but even now I do n't understand , which connections are we speaking about ? /In the case that the application signals that the initial   is failing for some reason and that another option should be attempted , the Connection can be updated to point to the next candidate   . This can be viewed as an application - driven form of   racing./ I think I could understand , ... but actually unsure really what this is about . I think this may be OK : / If the Selection Properties allow multiple protocols to be used for listening , and the implementation supports it , the  object should register across the eligble protocols for each path . This means that inbound Connections delivered by the implementation may have heterogeneous protocol  however , I do n't fully understand this text . /These map well into Connection objects./ /map  or /map/ or do I miss something ? /it limits the required checksum in protocols / should be : / it sets the minimum protection in protocols/ /Transmission Profile : TBD - because it 's not final in the API yet./ NOT defined . 
 lgtm , just 2 nitsThanks  , LGTM !
Paragraph (version A):
If a connection originally targets a single endpoint, there may be
multiple endpoints of different types that can be derived from the
original.  The connection library should order the derived endpoints
according to application preference, system policy and expected
performance.
Paragraph (version B):
If a connection originally targets a single endpoint, there may be
multiple endpoints of different types that can be derived from the
original.  The connection library creates an ordered list of the
derived endpoints according to application preference, system policy
and expected performance.
Paragraph (version A):
DNS-Based Service Discovery RFC6763 can also provide an endpoint
derivation step.  When trying to connect to a named service, the
client may discover one or more hostname and port pairs on the local
network using multicast DNS RFC6762.  These hostnames should each be
treated as a branch which can be attempted independently from other
hostnames.  Each of these hostnames may also resolve to one or more
addresses, thus creating multiple layers of branching.
Paragraph (version A):
If a client has multiple network interfaces available to it, such as
mobile client with both Wi-Fi and Cellular connectivity, it can
attempt a connection over either interface.  This represents a branch
point in the connection establishment.  Like with derived endpoints,
the interfaces should be ranked based on preference, system policy,
and performance.  Attempts should be started on one interface, and
then on other interfaces successively after delays based on expected
round-trip-time or other available metrics.
Paragraph (version B):
DNS-Based Service Discovery RFC6763 can also provide an endpoint
derivation step.  When trying to connect to a named service, the
client may discover one or more hostname and port pairs on the local
network using multicast DNS RFC6762.  These hostnames should each be
treated as a branch that can be attempted independently from other
hostnames.  Each of these hostnames might resolve to one or more
addresses, which would create multiple layers of branching.
Paragraph (version B):
If a client has multiple network interfaces available to it, e.g., a
mobile client with both Wi-Fi and Cellular connectivity, it can
attempt a connection over any of the interfaces.  This represents a
branch point in the connection establishment.  Similar to a derived
endpoint, the interfaces should be ranked based on preference, system
policy, and performance.  Attempts should be started on one
interface, and then on other interfaces successively after delays
based on expected round-trip-time or other available metrics.
Paragraph (version A):
This approach is commonly used for connections with optional proxy
server configurations.  A single connection may be allowed to use an
HTTP-based proxy, a SOCKS-based proxy, or connect directly.  These
options should be ranked and attempted in succession.
Paragraph (version A):
Implementations that support racing protocols and protocol options
should maintain a history of which protocols and protocol options
successfully established, on a per-network basis (see performance-
caches).  This information can influence future racing decisions to
prioritize or prune branches.
Paragraph (version B):
This approach is commonly used for connections with optional proxy
server configurations.  A single connection might have several
options available: an HTTP-based proxy, a SOCKS-based proxy, or no
proxy.  These options should be ranked and attempted in succession.
Paragraph (version B):
Implementations that support racing protocols and protocol options
should maintain a history of which protocols and protocol options
successfully established, on a per-network and per-endpoint basis
(see performance-caches).  This information can influence future
racing decisions to prioritize or prune branches.
Paragraph (version A):
Branch types must occur in a specific order relative to one another
to avoid creating leaf nodes with invalid or incompatible settings.
In the example above, it would be invalid to branch for derived
endpoints (the DNS results for www.example.com) before branching
between interface paths, since usable DNS results on one network may
not necessarily be the same as DNS results on another network due to
local network entities, supported address families, or enterprise
network configurations.  Implementations must be careful to branch in
an order that results in usable leaf nodes whenever there are
multiple branch types that could be used from a single node.
Paragraph (version B):
Branch types must occur in a specific order relative to one another
to avoid creating leaf nodes with invalid or incompatible settings.
In the example above, it would be invalid to branch for derived
endpoints (the DNS results for www.example.com) before branching
between interface paths, since there are situations when the results
will be different across networks due to private names or different
supported IP versions.  Implementations must be careful to branch in
an order that results in usable leaf nodes whenever there are
multiple branch types that could be used from a single node.
Paragraph (version A):
Protocol options are checked next in order.  Whether or not a set of
protocol, or protocol-specific options, can successfully connect is
generally not dependent on which specific IP address is used.
Furthermore, the protocol stacks being attempted may influence or
altogether change the endpoints being used.  Adding a proxy to a
connection's branch will change the endpoint to the proxy's IP
address or hostname.  Choosing an alternate protocol may also modify
the ports that should be selected.
Paragraph (version B):
Protocol options are next checked in order.  Whether or not a set of
protocol, or protocol-specific options, can successfully connect is
generally not dependent on which specific IP address is used.
Furthermore, the protocol stacks being attempted may influence or
altogether change the endpoints being used.  Adding a proxy to a
connection's branch will change the endpoint to the proxy's IP
address or hostname.  Choosing an alternate protocol may also modify
the ports that should be selected.
Paragraph (version A):
For example, if the application has indicated both a preference for
WiFi over LTE and for a feature only available in SCTP, branches will
be first sorted accord to path selection, with WiFi at the top.
Then, branches with SCTP will be sorted to the top within their
subtree according to the properties influencing protocol selection.
However, if the implementation has cached the information that SCTP
is not available on the path over WiFi, there is no SCTP node in the
WiFi subtree.  Here, the path over WiFi will be tried first, and, if
connection establishment succeeds, TCP will be used.  So the
Selection Property of preferring WiFi takes precedence over the
Property that led to a preference for SCTP.
Paragraph (version A):
Implementations should sort the branches of the tree of connection
options in order of their preference rank.  Leaf nodes on branches
with higher rankings represent connection attempts that will be raced
first.  Implementations should order the branches to reflect the
preferences expressed by the application for its new connection,
including Selection Properties, which are specified in I-D.ietf-taps-
interface.
Paragraph (version B):
For example, if the application has indicated both a preference for
WiFi over LTE and for a feature only available in SCTP, branches will
be first sorted accord to path selection, with WiFi at the top.
Then, branches with SCTP will be sorted to the top within their
subtree according to the properties influencing protocol selection.
However, if the implementation has current cache information that
SCTP is not available on the path over WiFi, there is no SCTP node in
the WiFi subtree.  Here, the path over WiFi will be tried first, and,
if connection establishment succeeds, TCP will be used.  So the
Selection Property of preferring WiFi takes precedence over the
Property that led to a preference for SCTP.
Paragraph (version B):
Implementations should sort the branches of the tree of connection
options in order of their preference rank, from most preferred to
least preferred.  Leaf nodes on branches with higher rankings
represent connection attempts that will be raced first.
Implementations should order the branches to reflect the preferences
expressed by the application for its new connection, including
Selection Properties, which are specified in I-D.ietf-taps-interface.
Paragraph (version A):
Implementations should process properties in the following order:
Prohibit, Require, Prefer, Avoid.  If Selection Properties contain
any prohibited properties, the implementation should first purge
branches containing nodes with these properties.  For required
properties, it should only keep branches that satisfy these
requirements.  Finally, it should order branches according to
preferred properties, and finally use avoided properties as a
tiebreaker.  When ordering branches, an implementation may give more
weight to properties that the application has explicitly set than to
properties that are default.
Paragraph (version B):
Implementations process properties in the following order: Prohibit,
Require, Prefer, Avoid.  If Selection Properties contain any
prohibited properties, the implementation should first purge branches
containing nodes with these properties.  For required properties, it
should only keep branches that satisfy these requirements.  Finally,
it should order branches according to preferred properties, and
finally use avoided properties as a tiebreaker.  When ordering
branches, an implementation may give more weight to properties that
the application has explicitly set than to properties that are
default.
Paragraph (version A):
This section covers the dynamic aspect of connection establishment.
While the tree described above is a useful conceptual and
architectural model, an implementation does not know what the full
tree may become up front, nor will many of the possible branches be
used in the common case.
Paragraph (version B):
This section covers the dynamic aspect of connection establishment.
The tree described above is a useful conceptual and architectural
model.  However, an implementation is unable to know the full tree
before it is formed and many of the possible branches ultimately
might not be used.
Paragraph (version B):
Immediate, or simultaneous, racing should be avoided by
implementations.  This approach can consume network resources and
establish state that will not be used.
Paragraph (version A):
If a leaf node has successfully completed its connection, all other
attempts should be made ineligible for use by the application for the
original request.  New connection attempts that involve transmitting
data on the network should not be started after another leaf node has
completed successfully, as the connection as a whole has been
established.  An implementation may choose to let certain handshakes
and negotiations complete in order to gather metrics to influence
future connections.  Similarly, an implementation may choose to hold
onto fully established leaf nodes that were not the first to
establish for use as part of a Pooled Connection, see pooled-
connections, or in future connections.  In both cases, keeping
additional connections is generally not recommended since those
attempts were slower to connect and may exhibit less desirable
properties.
Paragraph (version B):
If a leaf node has successfully completed its connection, all other
attempts should be made ineligible for use by the application for the
original request.  New connection attempts that involve transmitting
data on the network ought not to be started after another leaf node
has already successfully completed, because the connection as a whole
has now been established.  An implementation may choose to let
certain handshakes and negotiations complete in order to gather
metrics to influence future connections.  Keeping additional
connections is generally not recommended since those attempts were
slower to connect and may exhibit less desirable properties.
Paragraph (version A):
However, if a peer is not reachable over the network using the
unconnected protocol, or data cannot be exchanged for any other
reason, the application may want to attempt using another candidate
Protocol Stack.  The implementation should maintain the list of other
candidate Protocol Stacks that were eligible to use.  In the case
that the application signals that the initial Protocol Stack is
failing for some reason and that another option should be attempted,
the Connection can be updated to point to the next candidate Protocol
Stack.  This can be viewed as an application-driven form of Protocol
Stack racing.
Paragraph (version B):
However, if a peer is not reachable over the network using the
unconnected protocol, or data cannot be exchanged for any other
reason, the application may want to attempt using another candidate
Protocol Stack.  The implementation should maintain the list of other
candidate Protocol Stacks that were eligible to use.
Paragraph (version A):
If the Selection Properties allow multiple protocols to be used for
listening, and the implementation supports it, the Listener object
should register across the eligble protocols for each path.  This
means that inbound Connections delivered by the implementation may
have heterogeneous protocol stacks.
Paragraph (version A):
Connected protocols such as TCP and TLS-over-TCP have a strong
mapping between the Local and Remote Endpoints (five-tuple) and their
protocol connection state.  These map well into Connection objects.
Whenever a new inbound handshake is being started, the Listener
should generate a new Connection object and pass it to the
application.
Paragraph (version B):
If the Selection Properties allow multiple protocols to be used for
listening, and the implementation supports it, the Listener object
should support receiving inbound connections for each eligible
protocol on each eligible path.
Paragraph (version B):
Connected protocols such as TCP and TLS-over-TCP have a strong
mapping between the Local and Remote Endpoints (five-tuple) and their
protocol connection state.  These map into Connection objects.
Whenever a new inbound handshake is being started, the Listener
should generate a new Connection object and pass it to the
application.
Paragraph (version A):
Corruption Protection Length: when this is set to any value other
than -1, it limits the required checksum in protocols that allow
limiting the checksum length (e.g.  UDP-Lite).
Paragraph (version A):
Transmission Profile: TBD - because it's not final in the API yet.
Old text follows: when this is set to "Interactive/Low Latency",
the Message should be sent immediately, even when this comes at
the cost of using the network capacity less efficiently.  For
example, small messages can sometimes be bundled to fit into a
single data packet for the sake of reducing header overhead; such
bundling should not be used.  For example, in case of TCP, the
Nagle algorithm should be disabled when Interactive/Low Latency is
selected as the capacity profile.  Scavenger/Bulk can translate
into usage of a congestion control mechanism such as LEDBAT, and/
or the capacity profile can lead to a choice of a DSCP value as
described in I-D.ietf-taps-minset).
Paragraph (version B):
Corruption Protection Length: when this is set to any value other
than -1, it sets the minimum protection in protocols that allow
limiting the checksum length (e.g.  UDP-Lite).