Added SCTP into docs.

Author: MaximProshin

Format.md

@@ -45,9 +45,9 @@ Example:
 In more detail, the JSON format consists of a bracketed sequence of records in braces. Each record has the following fields:
 
    * The "Event" field specifies what kind of event is being reported. This field can take on the following values: "new" for newly seen connections, "change" when the connection's identifying parameters such as port numbers of QUIC connection identifiers change, "delete" for connections deleted, "spinflip" for a flip of the QUIC spin bit in a connection, "spin" for any value of a spin bit in a QUIC connection, "measurement" for new RTT measurements, and "ecnce" for ECN-related events.
-   * The "Type" field specifies the type of a connection. This field can take on the following basic values: "UDP", "TCP", "QUIC", "DNS", "COAP", and "ICMP". In addition, it is possible to specify aggregate connections; these take on the following types: "HOSTS" for a host-to-host aggregate, "H2NET" for a host-to-network aggregate, "NET2NET" for a network-to-network aggregate, and "MCAST" for a multicast group aggregate.
+   * The "Type" field specifies the type of a connection. This field can take on the following basic values: "UDP", "TCP", "QUIC", "DNS", "COAP", "ICMP" and "SCTP". In addition, it is possible to specify aggregate connections; these take on the following types: "HOSTS" for a host-to-host aggregate, "H2NET" for a host-to-network aggregate, "NET2NET" for a network-to-network aggregate, and "MCAST" for a multicast group aggregate.
    * The "Addrs" field specifies addresses associated with the connection or aggregate.
-   * The "Session" field specifies the session identifiers associated with the connection, if any. For TCP and UDP connections these are the port numbers, for QUIC the connection IDs, and for ICMP the identifier field.
+   * The "Session" field specifies the session identifiers associated with the connection, if any. For TCP and UDP connections these are the port numbers, for QUIC the connection IDs, for ICMP the identifier field and for SCTP the verification tags and the port numbers.
    * The "Ts" is the timestamp, number of microseconds since the start of January 1, 1970. Note that the number is represented as an integer, given that the 53 bits of integer precision in JSON integers is sufficient. About 20 bits are needed for the microseconds part, which leaves 43 bits for the integer seconds parts; enough until year 280892.
    * The "State" field is the state of the connection, either "Starting", "Up", "Closing", or "Closed".
 

Library.md

@@ -37,7 +37,7 @@ Finally, you need to clean up the resources used by the analyzer. Like this:
 
     spindump_analyze_uninitialize(analyzer);
 
-That's the basic usage of the analyzer, using the built-in functions of looking at TCP, QUIC, ICMP, UDP, and DNS connections and their roundtrips.
+That's the basic usage of the analyzer, using the built-in functions of looking at TCP, QUIC, ICMP, UDP, DNS, and SCTP connections and their roundtrips.
 
 The software does not communicate the results in any fashion at this point; any use of the collected information about connections would be up to the program that calls the analyzer; the information is merely collected in an in-memory data structure about current connections. A simple use of the collected information would be to store the data for later statistical analysis, or to summarize in in some fashion, e.g., by looking at average round-trip times to popular destinations.
 
@@ -77,7 +77,7 @@ But in the end, when a handler has been registered, if the noted event occurs th
 
 In the first part of the code above, a handler is registered to be called upon seeing a new RTT measurement being registered. The second part of the code is the implementation of that handler function. In this case, once a measurement has been made, the function "myhandler" is called. The packet that triggered the event (if any) is given by "packet" and the connection it is associated with is "connection". For the connection delete events (as they can come due to timeouts), the packet structure is otherwise empty except for the timestamp (packet->timestamp) of the deletion.
 
-All RTT measurements and other data that may be useful is stored in the connection object. See spindump_connections_struct.h for more information. For instance, the type of the connection (TCP, UDP, QUIC, DNS, ICMP) can be determined by looking at the connection->type field.
+All RTT measurements and other data that may be useful is stored in the connection object. See spindump_connections_struct.h for more information. For instance, the type of the connection (TCP, UDP, QUIC, DNS, ICMP, SCTP) can be determined by looking at the connection->type field.
 
 The RTT data can be accessed also via the connection object. For instance, in the above "myhandler" function one could print an RTT measurement as follows:
 
@@ -120,7 +120,7 @@ See the API functions in the [Analyzer API definition](https://github.com/Ericss
 
 This object represents a single connection observed by the analyzer. The full description of that object needs to be added later, but here are some of the key fields that are relevant:
 
-* connection->type indicates the type of the connection (TCP, ICMP, QUIC, etc)
+* connection->type indicates the type of the connection (TCP, ICMP, QUIC, SCTP, etc)
 * connection->creationTime indicates when the first packet for the connection was seen
 * connection->packetsFromSide1 counts the number of packets sent from the initiator to the responder 
 * connection->packetsFromSide2 counts the number of packets sent from the initiator to the initiator 

README.md

@@ -4,7 +4,7 @@
 
 The "Spindump" tool is a Unix command-line utility that can be used for latency monitoring in traffic passing through an interface. The tool performs passive, in-network monitoring. It is not a tool to monitor traffic content or metadata of individual connections, and indeed that is not possible in the Internet as most connections are encrypted.
 
-The tool looks at the characteristics of transport protocols, such as the QUIC Spin Bit, and attempts to derive information about round-trip times for individual connections or for the aggregate or average values. The tool supports TCP, QUIC, COAP, DNS, and ICMP traffic. There's also an easy way to anonymize connection information so that the resulting statistics cannot be used to infer anything about specific connections or users.
+The tool looks at the characteristics of transport protocols, such as the QUIC Spin Bit, and attempts to derive information about round-trip times for individual connections or for the aggregate or average values. The tool supports TCP, QUIC, COAP, DNS, ICMP, and SCTP traffic. There's also an easy way to anonymize connection information so that the resulting statistics cannot be used to infer anything about specific connections or users.
 
 The software is under development, and subject to research on best algorithms.
 

doc/api/analyzer.md

@@ -167,7 +167,7 @@ Called when there's an ECN congestion event from the responder (server) of a con
 
 The library allocates memory as needed using malloc and free, and upon calling the analyzer uninitialization function, no allocated memory remains.
 
-Some of the allocation sizes can be changed in the relevant header files or through -D flag settings in the makefiles. For instance, the default number of sequence numbers stored for tracking TCP ACKs and COAP requests is 50, as defined in src/spindump_seq.h:
+Some of the allocation sizes can be changed in the relevant header files or through -D flag settings in the makefiles. For instance, the default number of sequence numbers stored for tracking TCP ACKs, SCTP SACKs and COAP requests is 50, as defined in src/spindump_seq.h:
 
     #ifndef spindump_seqtracker_nstored
     #define spindump_seqtracker_nstored		50

doc/api/connection.md

@@ -8,7 +8,7 @@ The detailed data structure is as follows:
 
 This object represents a single connection observed by the analyzer. The full description of that object needs to be added later, but here are some of the key fields that are relevant:
 
-* connection->type indicates the type of the connection (TCP, ICMP, QUIC, etc)
+* connection->type indicates the type of the connection (TCP, ICMP, QUIC, SCTP, etc)
 * connection->creationTime indicates when the first packet for the connection was seen
 * connection->packetsFromSide1 counts the number of packets sent from the initiator to the responder 
 * connection->packetsFromSide2 counts the number of packets sent from the initiator to the initiator