Draft: draft-ietf-taps-impl

Commentary: This is a manual re - application of all the changes to -impl in PR . ( Other methods did n't easily work because the master has changed quite a bit during discussion of PR ; at least I found no easy way ) . 
 Sec 10.6 of taps - impl is pretty confusing : .. there 's yet more . Maybe I should read NEAT - flow - mapping , or remind myself about the details of SCTP , but I think the third sentence ( To map Connection Objects ... ) is not well - constructed . There are three conditions here : both SCTPs must : support 8260,support stream reconfiguration , ANDknow what 's going on . But what do these conditions enable ? Is it mapping connections to streams at all ? Is it mapping them without HOL blocking ( i.e. , if not met , I still can map but there is HOL blocking ) ? Something else ? 
  as charged ! I wrote this and I can fix it . Meanwhile , I 'll explain : 8260 = to reduce HOL blocking delay . stream reconfiguration = to save memory and be able to re - use stream numbers , and to realize the role of a FIN ( stream reset = FIN ) know what 's going on = yes , but this is an application requirement ... the applications on both sides must be able to handle this . E.g. , a server written over a TAPS system could just listen on all protocols , including streams , and get whatever kind of Connection ( including , possibly , one that 's really only a stream ) - and then answer on it ( I actually tested exactly this with NEATPy ) . This server can handle this easily . Another server could be a native TCP server , certainly not expecting SCTP , let alone Connections riding on streams - this server could not handle this . The client application , when connecting , must know what it 's doing . I can make a PR to explain these matters in the text .
Paragraph (version A):
Connection objects represent a flow of SCTP messages between a
client and a server, which may be an SCTP association or a stream
in a SCTP association.  How to map Connection objects to streams
is described in NEAT-flow-mapping; in the following, a similar
method is described.  To map Connection objects to SCTP streams
without head-of-line blocking on the sender side, both the sending
and receiving SCTP implementation must support message
interleaving RFC8260.  Both SCTP implementations must also support
stream reconfiguration.  Finally, both communicating endpoints
must be aware of this intended multiplexing; NEAT-flow-mapping
describes a way for a Transport System to negotiate the stream
mapping capability using SCTP's adaptation layer indication, such
that this functionality would only take effect if both ends sides
are aware of it.  The first flow, for which the SCTP association
has been created, will always use stream id zero.  All additional
flows are assigned to unused stream ids in growing order.  To
avoid a conflict when both endpoints map new flows simultaneously,
the peer which initiated the transport connection will use even
stream numbers whereas the remote side will map its flows to odd
stream numbers.  Both sides maintain a status map of the assigned
stream numbers.  Generally, new streams must consume the lowest
available (even or odd, depending on the side) stream number; this
rule is relevant when lower numbers become available because
Connection objects associated to the streams are closed.
Paragraph (version A):
If this is the only Connection object that is assigned to the SCTP
association or stream mapping has not been negotiated,
CONNECT.SCTP is called.  Else, unless the Selection Property
"activeReadBeforeSend" is Preferred or Required, a new stream is
used: if there are enough streams available, "Initiate" is just a
local operation that assigns a new stream number to the Connection
object.  The number of streams is negotiated as a parameter of the
prior CONNECT.SCTP call, and it represents a trade-off between
local resource usage and the number of Connection objects that can
be mapped without requiring a reconfiguration signal.  When
running out of streams, ADD_STREAM.SCTP must be called.
Paragraph (version A):
If this is the only Connection object that is assigned to the SCTP
association or stream mapping has not been negotiated,
CONNECT.SCTP is called with the "user message" parameter.  Else, a
new stream is used (see "Initiate" for how to handle running out
of streams), and this just sends the first message on a new
stream.
Paragraph (version A):
"Initiate" or "InitiateWithSend" returns without an error, i.e.
SCTP's four-way handshake has completed.  If an association with
the peer already exists, and stream mapping has been negotiated
and enough streams are available, a Connection Object instantly
becomes Ready after calling "Initiate" or "InitiateWithSend".
Paragraph (version A):
LISTEN.SCTP.  If an association with the peer already exists and
stream mapping has been negotiated, "Listen" just expects to
receive a new message on a new stream id (chosen in accordance
with the stream number assignment procedure described above).
Paragraph (version B):
Connection objects can be mapped to an SCTP association or a
stream in an SCTP association.  Mapping Connection objects to SCTP
streams is called "stream mapping" and has additional requirements
as follows.  The following explanation assumes a client-server
communication model.
Paragraph (version B):
Stream mapping requires an association to already be in place between
the client and the server, and it requires the server to understand
that a new incoming stream should be represented as a new Connection
Object by the Transport Services system.  A new SCTP stream is
created by sending an SCTP message with a new stream id.  Thus, to
implement stream mapping, the Transport Services system MUST provide
a newly created Connection Object to the application upon the
reception of such a message.  The necessary semantics to implement a
Transport Services system's Close and Abort primitives are provided
by the stream reconfiguration (reset) procedure described in RFC6525.
This also allows to re-use a stream id after resetting ("closing")
the stream.  To implement this functionality, SCTP stream
reconfiguration RFC6525 MUST be supported by both the client and the
server side.
Paragraph (version B):
To avoid head-of-line blocking, stream mapping SHOULD only be
implemented when both sides support message interleaving RFC8260.
This allows a sender to schedule transmissions between multiple
streams without risking that transmission of a large message on one
stream might block transmissions on other streams for a long time.
Paragraph (version B):
To avoid conflicts between stream ids, the following procedure is
recommended: the first Connection, for which the SCTP association has
been created, MUST always use stream id zero.  All additional
Connections are assigned to unused stream ids in growing order.  To
avoid a conflict when both endpoints map new Connections
simultaneously, the peer which initiated association MUST use even
stream ids whereas the remote side MUST map its Connections to odd
stream ids.  Both sides maintain a status map of the assigned stream
ids.  Generally, new streams SHOULD consume the lowest available
(even or odd, depending on the side) stream id; this rule is relevant
when lower ids become available because Connection objects associated
with the streams are closed.
Paragraph (version B):
SCTP stream mapping as described here has been implemented in a
research prototype; a desription of this implementation is given in
NEAT-flow-mapping.
Paragraph (version B):
If this is the only Connection object that is assigned to the SCTP
association or stream mapping is not used, CONNECT.SCTP is called.
Else, unless the Selection Property "activeReadBeforeSend" is
Preferred or Required, a new stream is used: if there are enough
streams available, "Initiate" is just a local operation that
assigns a new stream id to the Connection object.  The number of
streams is negotiated as a parameter of the prior CONNECT.SCTP
call, and it represents a trade-off between local resource usage
and the number of Connection objects that can be mapped without
requiring a reconfiguration signal.  When running out of streams,
ADD_STREAM.SCTP must be called.
Paragraph (version B):
If this is the only Connection object that is assigned to the SCTP
association or stream mapping is not used, CONNECT.SCTP is called
with the "user message" parameter.  Else, a new stream is used
(see "Initiate" for how to handle running out of streams), and
this just sends the first message on a new stream.
Paragraph (version B):
"Initiate" or "InitiateWithSend" returns without an error, i.e.
SCTP's four-way handshake has completed.  If an association with
the peer already exists, stream mapping is used and enough streams
are available, a Connection Object instantly becomes Ready after
calling "Initiate" or "InitiateWithSend".
Paragraph (version B):
LISTEN.SCTP.  If an association with the peer already exists and
stream mapping is used, "Listen" just expects to receive a new
message with a new stream id (chosen in accordance with the stream
id assignment procedure described above).
Paragraph (version A):
Calling "Clone" on an SCTP association creates a new Connection
object and assigns it a new stream number in accordance with the
stream number assignment procedure described above.  If there are
not enough streams available, ADD_STREAM.SCTP must be called.
Paragraph (version B):
Calling "Clone" on an SCTP association creates a new Connection
object and assigns it a new stream id in accordance with the
stream id assignment procedure described above.  If there are not
enough streams available, ADD_STREAM.SCTP must be called.
Paragraph (version A):
EVENT.SCTP informs the transport system that the stream number can
now be re-used by the next "Initiate", "InitiateWithSend" or "Listen"
calls, and invokes a "Closed" event towards the application.
Paragraph (version B):
EVENT.SCTP informs the Transport Services system that the stream id
can now be re-used by the next "Initiate", "InitiateWithSend" or
"Listen" calls, and invokes a "Closed" event towards the application.