Draft: draft-ietf-taps-arch

Commentary: Nicer text throughout to introduce key things consistently ; firm - up architecture v interface ; introduce properties ; resolve some NiTs . 
 Accepted adjustments from Tommy and merged . 
 I 'll have to read the document yet another time , perhaps , but after the few times I went through it for this review , I 'm still not clear on how / whether connections are grouped because of actions from the remote end(s ) . If so , how does the user learn about the grouping ? Does it have to poll Connection . GroupedConnections ( ) every time its told of a new Connection ? 
 I think the answer is that an application may be unaware whether incoming Connections are grouped or not . To get the information , polling Connection . GroupedConnections ( ) every time a new Connection arrives sounds just about right . But grouping can take various forms ... the most common that I think is on everyone 's mind is multi - streaming , where the arrival of a new stream is clear to the underlying stack . In this case , even when a stream is exposed as a Connection , the application can learn that it 's really grouped together with others by polling as you say . Another alternative for grouping is to couple the congestion control of connections ( [ RFC 8699 ] , or see [ 1 ] for how it can be done with TCP ) - e.g. , when they traverse the same tunnel , or when statistics give us a hint that there is a common bottleneck on the path [ RFC 8382 ] , [ 2 ] . In this case , the grouping is done one - sided . It 's also possible that calling clone ( ) really has no effect in the stack , because neither a multi - streaming capable transport nor such coupling mechanisms are available ; the Connections are then still " grouped " in that changing a property of one is expected to affect all the others , but this is irrelevant to the peer when the Connections really are , e.g. , separate TCP connections . All in all , I do n't think a text change is needed . [ 1 ] Safiqul Islam ,   ,   ,   , Grenville Armitage ,   : " ctrlTCP : Reducing Latency through Coupled , Heterogeneous Multi - Flow TCP Congestion Control " , IEEE INFOCOM Global Internet Symposium ( GI ) workshop ( GI 2018 ) , Honolulu , HI , April 2018 . [ 2 ]   ,   ,   ,   ,   : " Online Identification of Groups of Flows Sharing a Network Bottleneck " , IEEE / ACM Transactions on Networking 28(5 ) , pp . 2229 - 2242 , Print ISSN : 1063 - 6692 , Online ISSN : 1558 - 2566 October 2020 . DOI 10.1109 / TNET.2020 .. 
 A Connection Group is only a set of Connections that share properties and caches at the sender . I do n't think text is needed . 
 Where does the document state that a connection group is a concept only known to the sender ? 
 Aha ! I think that text may be needed . Thanks ! 
 Yes and " aha " - I am happy to add that a connection group is a concept at the sender to arch , I add in a pending PR to address " cloning " . I suggest MW does this for interface . 
 In 3.1 consider " It is important for applications using a Transport Services system to be robust to the " instead of using REQUIRED . At 3.2 , if this were a requirements document for the Transport Services system , the SHOULD in the first paragraph might make sense . But if its an architecture document , or better , an overview and introduction . It would be better to simply say " is " rather than SHOULD . ( And in a requirements document , I would argue that this SHOULD should be a MUST ) . 
 I think 3.1 probably needs a little more unpacking , this is a little abstarct in what is needed to say required : " Applications using a Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system , where the automated selection is constrained by the requirements and preferences expressed by the application . " We could therefore loose the /REQUIRED/. I 'll suggest this as a starting point for 3.1 - the topic here is not an interoperability requirement of the protocol on the wire , it is about whether the method needs to have the feature to satisfy the design goals : " It is therefore is RECOMMENDED that a Transport Services system permits more specialized protocol features to be used . " 
 this will be fixed with any reasonable fix to 
 Make it clearer in 3.1 that you are introducing a concept named  . A sentence that starts " Properties are " would really help . 
 Expected fixed in linked PR 
 The ( arch ) document currently says ( just before section 3.1 ) " The rest of this document describes the architecture non - normatively " , but then goes on to use a bunch of 2119/8174 language ( much of which really should n't be - please try eliminating all of them ) . 
 this will be fixed with any reasonable fix to 
 See lined PR first , before discussing please . 
 Early art - art review of draft - ietf - taps - architecture My first observation and request is that the group rethink the separation of the architecture and interface documents . It is a warning - sign that the interface document is a normative reference for the architecture document . As the documents are currently constructed , a new reader can not grasp the architecture without inferring some of it through reading the interface . Consider reformulating the architecture document as an overview - introduce principles , concepts , and terminology , but do n't attempt to be normative . ( There are signs that this may already be , or have been , a path the document was being pushed towards ) . If nothing else , rename it , and acknowledge that the actual architecture is specified using the interface definition . Note that the first sentence of the Overview in the interface document also highlights the current structural problem . 
 I do n't entirely agree with this ART - ART comment : I think I might well agree with moving more of the description to this  document , but as discussed before , I also think it useful here to set the actual requirements for the architecture , and to define the architecture . It may need to be much clearer that this architecture consists of more the API . 
 For completeness , this is the first statement of the interface document review : This document reads fairly well . I have some structural concerns ( see the early review of the architecture document ) . In particular I think this document contains the actual definition of the architecture and some of that is inferential . 
 Discussion at September 2021 interim : pass through this document with a view toward making it a high level introduction , not an architecture definition : " An Introduction to the Transport Services Architecture " . remove normative language from this document ( moving it to API , where necessary ) . move details not useful in a high level intro to API . 
 I disagree with this conclusion at first pass — we did a specific analysis and pass on this over a year ago , with PR . The normative language and the standards - track aspect was very intentional and something the WG had consensus on . The point is that the API is a specific incarnation of the TAPS architecture , but there are overarching architectural properties that go beyond a specific abstract API . 
 I completely agree with  here , and recommend we fix this in . We should also of course check for any stray text or missing concepts . I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system . 
 See linked PR first please to see if this resolves this ? 
 A PR was merged that addressed important text issues with separation of requirements and overview , and should more clearly set out that the requirements are for the system . The question of whether the overall TAPS systems requirements belong in this ID ; the API ; or a separate RFC needs some discussion based on the review , before this can be closed . 
 Many good text improvements in the PR but I noticed two smaller updates in the PR that I think were incorrect . Fixed in 
 The review comment showed were many places where the wording of architecture can be improved . There are some high level principles that I think should remain in the architecture document . The decision in today 's interim is to review the architecture to get this more into a shape that is valuable as a reference , and then check the updated draft . 
 I now suggest the issues are addressed and we close this issue without moving text between documents 
 I agree with that ; closing .
Paragraph (version A):
This document describes an architecture for exposing transport
protocol features to applications for network communication, the
Transport Services architecture.  The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern.  This uses messages for representing data
transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and
provide multiple application streams.  This document further defines
common terminology and concepts to be used in definitions of
Transport Services APIs and implementations.
Paragraph (version B):
This document describes an architecture for exposing transport
protocol features to applications for network communication, the
Transport Services architecture.  The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern.  This API uses messages for representing data
transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and
provide multiple application streams.  This document further defines
common terminology and concepts to be used in definitions of
Transport Services APIs and implementations.
Paragraph (version A):
There are several degrees in which a Transport Services system is
intended to offer flexibility to an application: it can provide
access to multiple sets of protocols and protocol features; it can
use these protocols across multiple paths that could have different
performance and functional characteristics; and it can communicate
with different remote systems to optimize performance, robustness to
failure, or some other metric.  Beyond these, if the API for the
system remains the same over time, new protocols and features can be
added to the system's implementation without requiring changes in
applications for adoption.  Similarly this can provide a common basis
for utilising information about a a network path or interface,
enabling evolution below the transport layer.
Paragraph (version B):
There are several degrees in which a Transport Services system is
intended to offer flexibility to an application: it can provide
access to multiple sets of protocols and protocol features; it can
use these protocols across multiple paths that could have different
performance and functional characteristics; and it can communicate
with different remote systems to optimize performance, robustness to
failure, or some other metric.  Beyond these, if the API for the
system remains the same over time, new protocols and features can be
added to the system's implementation without requiring changes in
applications for adoption.  Similarly, this can provide a common
basis for utilizing information about a network path or interface,
enabling evolution below the transport layer.
Paragraph (version A):
An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via
Properties.  Properties are used by an applicatioon to declares its
preferences for how the transport service should operate at each
stage of the lifetime of a connection.  Transport Properties are
subdivided into Selection Properties, which specify which paths and
protocol stacks can be used and are preferred by the application;
Connection Properties, which inform decisions made during connection
establishment and to fine-tune the established connection and Message
Properties, set on indvidual Messages.
Paragraph (version B):
An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via
Properties.  Properties are used by an application to declare its
preferences for how the transport service should operate at each
stage in the lifetime of a connection.  Transport Properties are
subdivided into Selection Properties, which specify which paths and
protocol stacks can be used and are preferred by the application;
Connection Properties, which inform decisions made during connection
establishment and fine-tune the established connection; and Message
Properties, set on individual Messages.
Paragraph (version A):
A Transport Services implementation can select Protocol Stacks based
on the Selection and Connection Properties communicated by the
application and any security parameters.  If two different Protocol
Stacks can be safely swapped, or raced in parallel (see racing), then
they are considered to be "equivalent".  Equivalent Protocol Stacks
are defined as stacks that can provide the same Transport Properties
and interface expectations as requested by the application.
Paragraph (version B):
A Transport Services implementation can select Protocol Stacks based
on the Selection and Connection Properties communicated by the
application, along with any security parameters.  If two different
Protocol Stacks can be safely swapped, or raced in parallel (see
racing), then they are considered to be "equivalent".  Equivalent
Protocol Stacks are defined as stacks that can provide the same
Transport Properties and interface expectations as requested by the
application.