musctp_draft.txt

   !!! ЧЕРНОВИК !!!

     muSCTP: Multiflow Unsymmetric Sessionful Concise Tunneled Protocol
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Универсальный транспортный протокол, предоставляющий прикладному коду сервис,
аналогичный TCP или SCTP, то есть надежную доставку данных, при этом могущий
работать по нескольким транспортным путям одновременно (как failover, так и
повышение производительности), и поддерживающий мультиплексирование в одном
соединении (ассоциации) сразу несколько байтовых TCP-потоков или передачи
разграниченных блоков данных, как в SCTP или Win32 CreateNamedPipe() в
режиме PIPE_TYPE_MESSAGE. Ключевой особенностью протокола является расчет
на работу в средах с очень малым размером пакета и с несимметричностью
сторон соединения - когда сервер в состоянии только отвечать на пакеты
клиента, но не посылать их самостоятельно, например, поверх ICMP-запросов и
ответов (однако если самостоятельные пакеты от сервера иногда возможны,
поддерживается и это).

A siginficant adavantage of muSCTP over QUIC is multipath: e.g. a mobile host
with both EDGE and Wi-Fi connectivity can not only rapidly switch from one
to another (as in QUIC, in cases like network change/failure/NAT rebinding),
but use both Wi-Fi and EDGE links simultaneously, increasing bandwidth.

1. Введение.

Application-layer framing or application-level framing (ALF) is a method of allowing an application to use its semantics for the design of its network protocols.

This procedure was first proposed by D. D. Clark and David L. Tennenhouse.[1] It works as follows:

  *  The application splits the data into useful segments.
  *      These segments are called ADUs (application data units).
  *  The ADUs can be processed in any order.
  *  The lower layers keep the ADU borders.

TODO 30.11.24 describe that L4 knowing how many bytes app wants to transmit is
beneficial for things like scheduling over multipath and e.g. Section 6.3.1 of
RFC 9049 describes why Quick-Start should be for bulk flows
- 25.01.25 https://arxiv.org/pdf/2210.00714 about Homa has a good list of TCP
  problems in this respect, e.g. scheduling Shortest Remaining Processing Time
  for "task to completion" - may be additional attribute to message here?


[QUIC-APPLICABILITY]:
in comparison to QUIC, muSCTP does not need fallback protocol, tunnels are for this

QUIC problems: increased deadlock probabilty, 
   Once stream limits are reached, no more streams can be opened,
   which prevents applications using QUIC from making further progress

QUIC does not provide any mechanism for graceful connection termination;

QUIC DATAGRAM extension [RFC 9221] does not allow ordering inside streams or
window control, while muSCTP allows this,and time, for unordedered chunks


RFC 8546 wire image:
   is that all
   observable parts of a protocol's wire image will eventually be used
   by devices on path.  Consequently, changes or future extensions that
   affect the observable part of the wire image become difficult or
   impossible to deploy.

4.1: Integrity protection of the wire image may
   itself help protect against accidental invariance, because read-only
   wire images invite less meddling than path-writable wire images.  The
   techniques discussed in [USE-IT] may also be useful in further
   preventing accidental invariance and ossification.



for example, QUIC's spin bit (an ugly kludge for measuring RTT
by on-path observers) is easily replaced by unencrypted (but authenticated)
packets with HEARTBEAT, ECHO, ECNE_CWR and LINK_INFO options, while all other
packets could remain encrypted

"Let's simplify user interface features" paradigm is bad and wrong, as seen on example
of TCP-3 [IEN21] this leads to problems in strategic perspective; [RFC 9170]
also states about bad assumptions in the protocol design about performance constraints
(read: variable-length fields)


due to Unix Time is bad in long scale, Leap Seconds and other problems, this
protocol version MUST NOT be used in XXII century (recommended method will be
e.g. Julian Days or CCSDS DAY SEGMENTED TIME CODE), so, for this version,
tv_sec is simply limited to 32 bits (unsigned) and that's it.


https://apenwarr.ca/log/20170810 describes problems of WiFi repeaters and LTE
due to bridging - which can be solved by changing from 4-tuple, that is,
Connection Tag of muSCTP (TBD may be have it longer by variable-length bits?)

RFC 6830                          LISP                      January 2013
   Address Family Identifier (AFI):   AFI is a term used to describe an
      address encoding in a packet.  An address family currently
      pertains to an IPv4 or IPv6 address.  See [AFI] and [RFC3232] for
      details.  An AFI value of 0 used in this specification indicates
      an unspecified encoded address where the length of the address is
      0 octets following the 16-bit AFI value of 0.

RFC 8376:
   The DNS query/answer protocol as a precursor to other communication
   within the Time-To-Live (TTL) of a DNS answer is clearly problematic
   in an LPWAN, say where only one round-trip per hour can be used, and
   with a TTL that is less than 3600 seconds.  It is currently unclear
   whether and how DNS-like functionality might be provided in LPWANs.
-- muSCTP could be used directly with DNS as sockaddr?


https://ipj.dreamhosters.com/wp-content/uploads/2023/01/253-ipj.pdf :

THE INTERNET PROTOCOL JOURNAL
11
RPC Support
IP hosts commonly support just two transport services, UDP and
TCP. UDP is a simple datagram-delivery service. Data encapsulated
using UDP have no assured delivery. TCP, as we have seen, is a reli-
able streaming service. The TCP protocol repairs any packet loss or
changes to the delivered packet sequence.
Another model, namely the Remote Procedure Call (RPC) model,
emulates the functionality of procedure calls, and rather than the byte-
stream model of TCP or the datagram model of UDP, the RPC model
is a reliable request/reply model, where the reply is uniquely associated
with the request. Perhaps the most well-known example today of an
RPC framework is gRPC[8]. gRPC is based on an HTTP/2 platform,
implying that the framework is susceptible to head-of-line blocking as
with any other TCP-based substrate.
The issue here is that a reliable byte stream is not the right abstrac-
tion for RPC, as the core of RPC is a request/reply paradigm, which
is more aligned to a reliable messaging paradigm, with all that such
a paradigm entails. A capable RPC framework needs to handle lost,
mis-ordered, and duplicated messages, with an identifier space that
can match requests and responses. The underlying message transport
needs to handle messages of arbitrary size, which entails packetization
adaptation within the transport.
The bidirectional stream framework is a reasonable match to the RPC
communications model where each RPC can be matched against an
individual stream. The stream is reliable and sequenced. The data
framing is not contained in QUIC, and it is still an application task to
add a record structure to an RPC stream, if that is what is required.
The invocation overhead is low in that the encrypted end-to-end con-
nection is already established.
It certainly appears that HTTPS behaves much more like RPC than
a reliable byte stream. That can benefit applications that run over
HTTP(S), such as gRPC, and a set of Representational State Transfer
(REST)ful APIs.

Load-Balancing QUIC
In today’s world of managing scale, it is very common to place a front-
end load balancer across many servers. The load balancer in the TCP
world typically categorizes packets as being in the same TCP session
because of a common 5-tuple value of protocol, IP addresses, and port
numbers, with the confident assurance that this value is stable for the
life of the TCP session.
QUIC offers no such assurances. The 5-tuple load-balancing approach
can work, but if the client is behind a NAT that performs what could be
called “aggressive” rebinding, then any such load-balancing approach
will be thrown. The reason why is that UDP does not provide session
signalling to a NAT, so there is no a priori assurance that the NAT
bindings (and the presented source address and port) will remain con-
stant for the entire QUIC session.
THE INTERNET PROTOCOL JOURNAL
12
Now in theory IPv6 could invoke the Flow-ID to provide a proxy
persistent field that remains constant for a flow, but the Flow-ID is of
limited size and has no assurances of uniqueness, as well as evidence
of highly variable treatment by IPv6 network infrastructure and end
hosts.
This topic touches upon a major assumption in today’s high-capacity
server infrastructure on the public Internet. Data streams use TCP and
the DNS uses UDP. Using UDP to carry sustained high-volume streams
may not match the internal optimisations used in server content-deliv-
ery networks.
DDoS Defence
The next issue here is exposure to Distributed Denial-of-Service
(DDoS) attacks. An attacker can send a large volume of packets to
the server and cause the server to perform work to attempt to decrypt
the packet. For this capability to be successful in TLS over TCP the
attacker must make a reasonable guess of the TCP sequence number
and window size for the packet to be accepted and passed to the TLS
decoder. QUIC has no lightweight packet filter before the decoder is
invoked.
On the other hand, the session encryption uses symmetric crypto
algorithms, which are less of a load on the receiver to decode than
asymmetric encryption. Is this difference enough to allow large-scale
QUIC platforms that are DDoS resistant to be constructed? I’m unsure
if there are clear answers here, but it seems that it’s part of the cost of
having a more complete encryption framework, which in itself appears
to be sorely needed on the public Internet.
Private QUIC
For private contexts, can QUIC negotiate a “null” TLS encryp-
tion algorithm? There is a bigger world out there beyond the public
Internet, and in many private data centre environments the overheads
of encrypting and decrypting packets may appear to be unnecessary.
While QUIC can present some clear advantages in terms of suitability
to complex application behaviours in the data centre that can lever-
age QUIC’s multi-stream capability, the cost of encryption may be too
high.
Of course, there is nothing stopping an implementation using a null
encryption algorithm, but such an implementation could talk only
to other implementations of itself. Strictly speaking, if you remove
encryption, then it’s no longer QUIC and it won’t interoperate with
anything else that is QUIC.
QUIC and OpenSSL
It useful to ask that if QUIC has such clear advantages over TCP, then
why hasn’t the adoption of QUIC been rapid? Metrics of QUIC use
tend to point to a use rate of some 30% of web sessions (such as
Cloudflare’s Radar report[9]).
QUIC and TCP continued
THE INTERNET PROTOCOL JOURNAL
13
However, if you alter the measurement to measure the extent to which
browsers on end systems are capable of supporting a QUIC session,
then the measurement jumps to 60%[10].
There are a couple of reasons why QUIC use is far lower than QUIC
capability. The first is that the Chrome browser still relies on the con-
tent-level switch to QUIC, so the client has to visit the site for the first
time using HTTP/2 (TCP/TLS) and thereby receive an indication if the
server can support QUIC, and then on the second visit the client may
use QUIC. It’s not quite as simple as this, as HTTP/2 uses persistent
connection, so if the second visit is sufficiently close in time to the first,
then the HTTP/2 session will remain open and still be used. The Safari
browser is capable of using QUIC on first use because it is triggered by
the Service Binding (SVCB) record in the DNS, but the market share
of Safari is relatively small in comparison to QUIC.
The second reason lies in the web server environment. Many servers
rely on the OpenSSL TLS library[11], and so far, (November 2022)
OpenSSL does not include support for QUIC. QUIC is supported in
BoringSSL[12], but as the notes for BoringSSL state, BoringSSL is a
fork of OpenSSL that is designed to meet Google’s needs, and while
it works for Google, it may not work for everyone else. Google does
not recommend that third parties depend on BoringSSL. There is also
QuicTLS, a fork of OpenSSL that Akamai and Google support[13].
This fragmentation of OpenSSL is not exactly helpful, and the result
is that many server environments are waiting for OpenSSL to incorpo-
rate a QUIC library. This effort was delayed by the work on OpenSSL
release 3.0.0, and then the OpenSSL folks announced their intention
to provide a fully functional QUIC implementation, and this develop-
ment of a new QUIC protocol stack may further delay QUIC support
in OpenSSL by months, if not years.

TBD 18.04.25 incorporate some features of gRPC

TBD 28.07.25 look at paths with attributes from https://www.openconfig.net/docs/gnmi/gnmi-specification/ like `/a/b[name=b1]/c/d` (is it from YANG or independent?) and updating them like union_replace merge


1.1. Общий обзор.

   Ranging protocols (boundaries really are somewhat blurred) by upper scale:


      Very      . Low end     . Middle    . Higher   .   Very      . Ultra High
   constrained  .             . (today)   . end      . Highload    . (future)
                .             .           .          .             .
   IoT/Embedded . older hw    . casual    . low-end  . Big DC      .
                . and sw,     . user's    . servers, . servers,    .
                . future      . desktop   . VMs      . HPC clus-   .
                . embedded    .           .          . ters        .
                .             .           .          .             .
   < 1 Mbps,    . 10-100 Mbps . 1 Gbps,   . 10 Gbps, . 40-800 Gbps . > 8 Tbps
   MTU 60-128   . IPv4        . IPv4/IPv6 . IPv4/6   . IPv6/custom .
   Bytes        \__ MTU 576-1500 Bytes __/ \_ MTU 1500-9000 Bytes _/
                .             .           .          .             .
   |<------ CoAP ------>|     .           .          .             .
                .             .           .          .             .
             |<----------------------- TCP ----------------------->|
                .             .           .          .             .
          |<------------------------ muSCTP ------------------------>|
                .             .           .          .             .
                .   |<--------------------- SCTP --------------------->|
                .             .           .          .             .
                .     |<--------------------- DCCP --------------------->|
                .             .           .          .             .
                .         |<-------------------- QUIC -------------------->|
                .             .           .          .             .
   |<-------x-----x--- custom protocols per task / field ---x--------x------->|

   In what SCTP is better performing than muSCTP:

   * up to 65536 theoretical streams instead of 256
   * same 32 bits for TSN, but chunk size is 2048 bytes maximum in muSCTP and
     65536 in SCTP so possible max speed is 32 times more (this requires,
     however, adding Window Scale INIT parameter like in TCP)
   * unlimited message size, compared to 1 Gb of muSCTP - and unlimited message
     is conceptually the same as opening and closing bytestream in QUIC
   * multiple peers in one socket, though this is API feature, not of protocol
     itself

   In all other respects muSCTP is better and have more features than SCTP
   (and, of course, TCP). And as QUIC is in fact 61-bit protocol with
   non-circular number space - it must be stopped on reaching this limit - it
   is also limited and not final word in protocols developing to match hardware
   speed.

  Базируется в основном на SCTP (RFC 4960) и некоторых идеях из CoAP (RFC 7252).
  Кроме того, поддерживается прозрачное для пользователя шифрование, подобное
  TLS/SSL (или же IPsec, если смотреть с точки зрения транспортов).

  Другой ключевой особенностью протокола является не самостоятельная работа
  напрямую поверх IP или UDP, но поверх некоторого другого, более простого
  туннельного протокола, обеспечивающего контроль целостности чексуммами
  (например, поверх UDP), но не гарантирующего доставки данных, и являющегося
  клиент-серверным модели "запрос-ответ" вплоть до 1 пакета, как в ICMP. С точки
  зрения пользователя muSCTP, т.е. кода приложения: 


                   +-------------+            
    OSI Layer 7    | application |          
                   +-------------+
                         |
                   +-------------+
    OSI Layer 5    | Session/QoS |
                   +-------------+
    OSI Layer 4    |   muSCTP    |
                   +-------------+
	               | |    |
	       .-------' |    `---,
	       |         |         |
   backends ===|=========|=========|===[ шифрование и проверка целостности ]===
	       |         |         |
	     +-----+  +------+  +-----------+
    Layer 3  | UDP |  | ICMP |  | HTTP+CoAP |
             +-----+  +------+  +-----------+

  С точки зрения реальной модели OSI, конечно, сами транспорты ("бэкенды")
  находятся на Layer 7.

  Поскольку транспорты возможны очень разные, и единственное, что их объединяет,
  это "отражение" сервером в ответе на запрос клиенту некоторого количества
  идентифицирующих байт, то собственно шифрование вынесено на уровень
  транспортных бэкендов, и даже сам пакет muSCTP, таким образом, состоит из
  более чем одной части: собственно тела, и повторяемая идентифицирующая часть:
  
     Client                                                           Server
       |                                                                 |
       |  +---------------------+                                        |
       |  | client packet body  |                              request   |
       |  +---------------------+--,  +------------------+  by protocol  |
       |                            >-| transport packet |-------------->|
       |  +---------------------+--'  +------------------+  of transport |
       |  | uniq. identificator |                                        |
       |  +---------------------+                                        |
       |                                        +---------------------+  |
       |    response                            | server packet body  |  |
       |  by protocol   +------------------+  .-+---------------------+  |
       |<---------------| transport packet |-<                           |
       |  of transport  +------------------+  `-+----------------------+ |
       |                                        |  same identificator  | |
       |                                        +----------------------+ |
       |                                                                 |

  Как именно эти части упаковываются в протокол конкретного транспорта, дело
  сугубо бэкенда этого транспорта. Концептуально, это может происходить как
  как непосредственными вызовами функций с аргументами (комбинированная
  реализация типична для клиента), так и разными процессами, возможно, на
  разных физических машинах, в случае сервера (соответственно с
  промежуточными мини-протокола) - в случае сервера, для обеспечения
  Highload, высоконагруженной системы на большое количество клиентов. В
  действительности, идентификатор состоит из отдельных частей:

     +---------------+  +---------+  +-------------+  +-------+
     | Server number |  | Counter |  | Key number  |  | Nonce |
     +---------------+  +---------+  +-------------+  +-------+

  Проблема короткоопакетных протоколов - малое количество байт  на
  идентификатор соединения. Тогда как в полноценном TCP/IP есть еще:

    * номер порта клиента, 16 бит
    * номер порта сервера, 16 бит

  В итоге высока вероятность коллизий, при большом количестве клиентов за
  одним IP-адресом (типично при NAT), что ведет к обрыву соединений. При
  этом в SCTP/IP не достаточно и этого, потому что соединение (ассоциация)
  может идти по нескольким маршрутам - так что добавлены еще дополнительные:

    * Client Verification Tag, 32 бита
    * Server Verification Tag, 32 бита 

  Причем они разные для сервера и клиента из соображений безопасности. Мы
  обеспечиваем безопасность и шифрование, так что повторяем эту схему, но
  на неё нет места в идентификаторе пакета, поэтому теги уходят в тело, а
  в идентификаторе остается другая важная часть - "номер сервера". Это аналог
  tcp-порта на сервере, но он применяется не как порт как таковой, а как
  средство распределения нагрузки:

    * при установке соединения клиент посылает на нулевой номер сервера
    * ему приходит ответ, с каким номером сервера дальше будет работа
    * далее клиент посылает запросы уже на этот номер сервера

  Так достигается балансировка нагрузки на сервер (эти номера могут быть,
  например, на разных физических машинах).

  К сожалению, из повтора сервером, Nonce не в полной мере оправдывает свое
  название, эта проблема будет решена другим путем.

TBD переименовать Verification, разобраться с Nfewnce, clarify "вместо портов"
TBD a host-to-host problem - SCTP has ports:
   o  SCTP association: A protocol relationship between SCTP endpoints,
      composed of the two SCTP endpoints and protocol state information
      including Verification Tags and the currently active set of
      Transmission Sequence Numbers (TSNs), etc.  An association can be
      uniquely identified by the transport addresses used by the
      endpoints in the association.  Two SCTP endpoints MUST NOT have
      more than one SCTP association between them at any given time.
   B) "Z" shall respond immediately with an INIT ACK chunk.  The
      destination IP address of the INIT ACK MUST be set to the source
      IP address of the INIT to which this INIT ACK is responding.  In
      the response, besides filling in other parameters, "Z" must set
      the Verification Tag field to Tag_A, and also provide its own
      Verification Tag (Tag_Z) in the Initiate Tag field.
so what to do when no ports?
TBD reflection problem for Key ID


  Номер ключа представляет собой аналог SPI из IPsec, то есть индекс
  использованных параметров шифрования - помимо собственно строки байт ключа,
  ключ данного номера имеет прикрепленную информацию в виде срока действия,
  алгоритмов; так же разные транспорты могут использовать разные байтовые
  подстроки ключа для уменьшения вероятности взлома других направлений при
  проблемах с одним из них. Сам muSCTP не занимается непосредственно
  шифрованием, это делают бэкенды, но занимается согласованием этих параметров
  и самих ключей, ротацию ключей, загрузку их в бэкенды. Ключи с очень низкими
  номерами зарезервированы (не ротируются, вшиты), в частности, ключ номер 0
  "пустой", означает отсутствие шифрования.

  Наконец, счетчик представляет из себя просто инкрементирующийся с каждым
  пакетом номер, служащий в основном цели уникальности пакета за некоторый
  период времени (исключением является только установление соединения). Это
  решает проблему наивных решений, когда счетчик есть непосредственно номер
  блока, причем общим для клиента и сервера, что создавало проблемы при
  закрытом окне и большом расхождении блоков на клиенте и сервере друг от
  друга. Кроме того, оно также ограничивало количество возможных ретрансмиссий
  для блока (Rand-битами), каковой проблемы не имеют обычные протоколы, и
  соответствено серьезно ограничивало применимость алгоритма Fast Retransmit.

  Внутри "контейнера" под идентификатором протокол майнтейнит свои номера,
  имитируя полноценный неограниченный схемой "запрос-ответ" протокол, и в
  случае поддерживающего такое транспорта сервер даже может отправить клиенту
  несколько пакетов с одинаковым идентификатором, но разным содержимым
  внутри.

1.2. Пути, потоки и блоки: удобство программной модели.

  Прежде всего, с точки зрения администратора, muSCTP может одновременно
  работать по нескольким путям, т.е. адресам.

  Рассмотрим обыкновенный классический TCP:
     
       _____________                                      _____________
      |  TCP User   |                                    |   TCP User  |
      | Application |                                    | Application |
      |-------------| address 1     data       address 2 |-------------|
      |     TCP     |<---------------------------------->|      TCP    |
      |  Transport  | port 1     byte stream      port 2 |  Transport  |
      |   Service   |                                    |   Service   |
      |_____________|                                    |_____________|

  В обычном TCP всё просто - у каждого конца только один адрес и порт. Данные
  представляют собой неструктурированный поток байт - сколько записали,
  столько в итоге прочитает получатель, но вовсе не факт, что такими же
  порциями. Поэтому в ряде прикладных протоколов программистам приходится
  самостоятельно каким-либо способом размечать (делить) поток на записи,
  часто указанием какой-либо длины.

  Если соединение в TCP порвалось, то... оно порвалось, ничего сделать нельзя,
  только установить новое (если получится).

  А в muSCTP возможна параллельная работа:

       _____________                                      _____________
      | muSCTP User |                                    | muSCTP User |
      | Application |                                    | Application |
      |-------------| address 1     data       address 4 |-------------|
      |   muSCTP    |<---------------------------------->|   muSCTP    |
      |  Transport  |                                    |  Transport  |
      |   Service   |                                    |   Service   |
      |-------------| address 2     data       address 5 |-------------|
      |             |<---------------------------------->|             |
      | Transport   |                \/                  | Transport   |
      |  backends   | address 3      /\        address 6 |  backends   |
      |_____________|<---------------------------------->|_____________|
                                    fail
      muSCTP Node A                                       muSCTP Node B

  То есть, в одно "соединение" - теперь оно называется "ассоциация" - внизу
  вовлекается несколько реальных соединений по разным адресам. И данные
  бегают по всем из них сразу, параллельно, вероятно, повышая скорость
  работы. Теперь, если одно из нижележащих "соединений" обрывается - это
  обнаруживается, и muSCTP переотправляет данные по другим путям. И в целом
  соединение (ассоциация) не рвётся - что, как минимум, удобно при
  интерактивной работе (шелл).

  Так, например, изначально ассоциация muSCTP могла быть установлена на адрес
  UDP-сервера, затем тот сообщил клиенту - "у меня есть еще ICMP-туннель", и
  клиент добавляет ICMP-адрес, и данные начинают ходить по обоим сразу. Далее,
  скажем, клиент может сообщить серверу "у меня получился коннект в HTTP",
  и они с сервером получают еще один канал для связи в той же ассоциации. При
  этом для пользователя, который уже, например, мог установить шелл-коннект
  через эту ассоциацию, всё происходит прозрачно - ничего не рвётся, всё
  работает, заново переустанавливать шелл-коннект на ставшее доступным более
  быстрое соединение вручную не надо. Всё автоматически.

  Это первейшее с точки зрения администратора, но есть более интересные вещи.

  Если соединение в TCP "застряло", то возникает более интересная ситуация.
  Допустим, программист делил на блоки и передавал по одному соединению данные
  параллельно - разные запросы, файлы и т.п. Когда временная ошибка, и поток
  застрял, тормозятся ВСЕ они - потому что TCP ничего не знает о структуре
  потока. Это называется head of line blocking, и для решения этой проблемы
  (то есть ускорения работы при одиночных ошибках) часто изобретают
  велосипеды, например, Google c протоколом QUIC по UDP. В них разделяют, что
  застрянет только один "поток" (HTTP-запрос), в котором произошла временная
  ошибка (потеря пакета), все остальные не затормозятся.

  muSCTP предоставляет возможность такого деления - поверх одной ассоциации
  может ходить несколько "логических" соединений - потоков. Например, по
  одному может быть шелл-коннект, по другому передача файла, по третьему
  SOCKS5 - это может и просто ssh, но ssh работает по tcp, и при обрыве или
  затыке заткнется всё. А в muSCTP только тот из потоков, который затронуло.
  И поскольку они имеют общие параметры, с точки зрения пользователя тут
  возможна и ПРИОРИТЕЗАЦИЯ - например, чтобы передача файла не забивала собой
  канал, как в старом решении, чтобы шеллу давался приоритет.

   stream messages
    +---+---+---+     entry
    |    0/0    |-,   to common "pipe"                            .-> stream 0
    +---+---+---+ |  \\                                        // | 
                  |   ## +---+---+---+---+---+---+---+---+---+ ## |
    +---+---+---+ '-> ## |2/0|1/2|0/0|2/0|1/1|0/0|2/0|1/0|0/0| ##-'
    |1/2|1/1|1/0|---> ## |---|---|---|---|---|---|---|---|---| ##---> stream 1
    +---+---+---+ .-> ## | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ##-,
                  |   ## +---+---+---+---+---+---+---+---+---+ ## |
    +---+---+---+ |   //  fragmenting messages to packets      \\ |
    |    2/0    |-'                                         exit  `-> stream 2
    +---+---+---+                              from common "pipe"
                                    +-------+
      +-------+                     |SID/SSN|
      |SID/SSN|  <- numbers mean -> |-------|
      +-------+                     |  TSN  |
                                    +-------+

  Для программиста же muSCTP предоставляет еще одно удобство - деление данных
  в потоках на блоки. То есть, отправка и чтение в каждый поток происходят с
  сохранением границ блоков - до 1 Гб. Получатель получит запись размера,
  который задал отправитель. Блоки отправляются и принимаются последовательно,
  каждый имеет номер, который увеличивается до максимума и снова начинает с
  нуля. Но есть и возможность отправить "внеочередной", unordered, блок, по
  потоку, не имеющий номера. Самый простой пример - послать Control-C в шелл
  или иные данные "сбоку". Итого как бы 16 пайпов с PIPE_TYPE_MESSAGE и
  еще 16 с типом по выбору, если говорить в терминах Win32 API.

  Ввиду специфики среды и малых пакетов, muSCTP поддерживает максимум 16
  потоков в одной ассоциации. Для удобства любой из них может быть переведен
  в "байтовый" режим, чтобы проще было передавать tcp-данные типа SOCKS5, а
  потом выведен. В байтовом режиме возможность посылать unordered-блоки
  сохраняется. Также для удобства при открытии байтового потока / в любой
  другой момент потоку может быть назначен произвольный DWORD, самим muSCTP
  не интерпретируемый, но к примеру, получатель может по нему понять, какой
  хэндлер открываемому потоку назначить, т.е. удобство протоколов поверх
  (аналог PPID в SCTP передается в каждом блоке, но здесь пакеты слишком
  короткие, чтобы тратить 4 байта на каждый блок, а вот время от времени можно).

   Some LPWAN technologies provide quasi-bidirectional connectivity,
   whereby a Downlink transmission from the Network Infrastructure can
   only take place right after an Uplink transmission by the Dev.

1.3. Philosophical background and values.

   attacks such as ALPACA

   mixing layers

   or disabling compression for individual messages - something simply not
   possible with byte streams:

   Some packet compression methods are known to be susceptible to
   attacks, such as BREACH and CRIME.  The attack involves injecting
   arbitrary data into the packet and observing the resulting compressed
   packet size.  The observed size potentially reflects correlation
   between the arbitrary data and some content that was meant to remain
   secret, such as a security token, thereby allowing the attacker to
   get at the secret.
Section 2.6 of [RFC7457]

2. Общий формат пакетов, идентификаторов и структур адресов.

  Здесь рассматриваются как пакет самого muSCTP внутри "контейнера" бэкенда
  транспортного протокола, так и минимально необходимых сопутствующих
  протоколов.

2.1. Идентификаторы.

  С точки зрения кода, идентификаторы представляют собой просто аргументы
  вызовов API, и как таковые не имеют формата, в частности endianness. В
  зависимости от туннеля, они могут иметь переменный размер

  Таким образом, размеры идентификаторов получаются:

    * Packet Counter - 4..19 бит
    * Sever instance Number - 6 бит
    * Shared Key Id - 6..8 бит
    * Random Nonce - битовая строка
    * Nfewnce - битовая строка, может отсутствовать


TODO

2.2. Структура адреса.

  Как внутри самого muSCTP при переконфигурациях дополнительных путей связи,
  так и во вспомогательных мини-протоколах, применяется структура адреса,
  представляющая по сути (без align) сериализованный стандартный

    struct sockaddr {
        uint8_t         sa_len;         /* total length */
        uint8_t         sa_family;      /* address family */
        char            sa_data[126];   /* to sockaddr_storage max size */
    };
RFC 3493
  То есть, 1 байт полной длины (включая саму длину), 1 байт типа адреса, и
  собственно данные адреса, зависящие от его типа. В отличие от низкоуровневой
  struct sockaddr, в muSCTP в основном применяются более высокоуровневые типы.

TBD CBOR for address #6.9426([ protocol_name: tstr / bstr, address: any, * params: any ])
and UDP port 9426 for tunnel "UDP-Example"
- this must be a range ports to solve INIT/ACK problem
  - how many enough, to 9444?
    - 11264 seems longer available range and 0x2c00 easier for debug

TBD djbernstein's MinimaLT https://cr.yp.to/tcpip/minimalt-20131031.pdf :
* allows data in first packet given client's ephemeral public key in it and server key in DNS, so may be put a key into CBOR tagged address?
* add puzzle as option to cookie?
* MinimaLT rekeying is indistinguishable from new connection

TBD better name than "tunnel" ?
- "bearer" from TIPC ? "carrier" ?

TBD there is AFI first appeared in RIPv2
<http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml>
do we need to suport it?
- there will be cases when AFI would be NULL, e.g. when address is "http://domain/url"
- probably may be paired with protocol number, to be able to have
  not only [1, "UDP", address...]
  but also e.g. [[1, 2], "UDP", address...] for both IPv4 and IPv6 ?
  - no, not array, coz v4 and v6 will have different addresses


TODO описать дерево в атомах, где их номера

2.3. Мини-протоколы инкапусуляции muSCTP.

  Для целей балансировки и поддержки высокой нагрузки как собственно сервер
  может состоять из ряда процессов, возможно, расположенных на разных
  физических машинах, так и транспортные бэкенды могут работать на разных
  машинах, вынося нагрузку по шифровке-расшифровке с сервера:

     tunnel                          mini-protocol
     protocols      +----------------+             +-------------------+
             .----> | UDP backend 1  |------------>| Server Instance 1 |
            /       +----------------+-.           +-------------------+
           /                            \
          /         +----------------+   \______   +-------------------+
         /   __,--> | UDP backend 2  |----------`=>| Server Instance 2 |
        |   /       +----------------+-.       ,-->+-------------------+
        |  |                            \     /
        v  v        +----------------+   \   /     +-------------------+
      clients <---> | ICMP backend 1 |----`=/=====>| Server Instance 3 |
        ^  ^        +----------------+\    /       +-------------------+
        |   \                          \  /
         \   \      +----------------+__\/         +-------------------+
          \   `---> | ICMP backend 2 |---\-=======>| Server Instance 4 |
           \        +----------------+    X        +-------------------+
            \                            / \
             \      +----------------+ -'   \      +-------------------+
              `---> | CoAP backend 1 |-------`====>| Server Instance 5 |
                    +----------------+             +-------------------+

  Это требует сохранения информации о том, от какого удаленного клиента был
  пакет, т.е. кому в итоге отвечать бэкенду. Кроме того, для балансировки
  бэкендам нужно знать загруженность каждого серверного процесса, не упал
  ли он, а также серверу загружать в бэкенды новые ключи.

  Это общение происходит по UDP, или, если выяснится, что на UDP большие потери
  либо необходимо шифрование этих данных из-за физически разнесенных площадок,
  по TCP с простым префиксом:

TBD как выполняется балансировка? не мало ли 8 байт Nonce max.? может
выделить отдельный OpType для инита, чтобы расширить Nonce до 16 байт?
- нет, не нужно, пусть бэкенды реальным Nonce дополняют, а этот будет Nfewnce

TODO

2.4. Общий формат тела пакета muSCTP.

  Пакет-"тело" внутри "контейнера", основная часть протокола, состоит из
  фикисированного заголовка, затем опций переменной длины, и, опционально,
  из дополнительных данных, который выполняют роль дополнительного
  payload, либо padding для криптографии (либо того и другого вместе).
  Особый случай - пакет установления соединения, в нём нет опций, см. ниже.
  Опции смоделированы из протокола CoAp, но на самом деле они не заголовки,
  как там, а аналог chunk в SCTP.

  Фиксированный заголовок на самом деле не совсем фиксированный, а может
  быть от 4 до 8 байт. Итого, пакет muSCTP в общем виде:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|M|               Connection Verification Tag               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .    0/1/2/4 bytes - Transmission Sequence Number (TSN) Base    .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 1 1 1 1|         Padding (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Здесь в фиксированном заголовке:

    * TSL - сколько байт поля TSN base реально присутствует в пакете:
      00 - 0 байт
      01 - 1 байт
      10 - 2 байта
      11 - 4 байта
    * Connection Verification Tag, 30 бит - свой для каждой стороны
      соединения, идентификатор соединения и проверка корректности,
      из него 1 бит R зарезервирован (и ДОЛЖЕН быть равен 0) на случай
      возможного внедрения мультикаста/групповых коммуникаций в будущем
    * Transmission Sequence Number (TSN) Base - базовое значение TSN для
      дальнейших опций.

protocol is built so that - except optional cryptographic part - only 32-bit
arithmetics is required from underlying hardware, and, in some cases, 64-bit
values in only logical/masking operations, effectively on subfileds, so that
e.g. 64 bits of Message ID split into 32 bits of time in second, 20 bits of
milliseconds, 10 bits stream and 2 bit flags - this could be parsed by
processing two 32-bit words

TBD 7 is too much for constrained, 6 max is enough, and only in c2s direction

TBD combine with M so M=1100 and above?
- then need change SRTLn in ABORT also

TFLL SocketID | non-constrained | constrained
0000 zero     | 4 bytes, indicate INIT packet
0000 non-zero | 4 bytes         | no CompressRule, as is
0001 any      | 5 bytes         | CompressRule=1
0010 any      | 6 bytes         | CompressRule=2
0011 any      | 7 bytes         | CompressRule=3
0100 zero     | Prohibited due to E / zero compression to T23
0100 non-zero | 8 bytes         | CompressRule=4
0101 any      | 10 bytes        | CompressRule=5
0110 any      | 12 bytes        | CompressRule=6
0111 any      | 14 bytes        | CompressRule=7
1000 non-zero | 16 bytes        | CompressRule=8
1000 zero     | 4 bytes, indicate error flag (ABORT packet)
1001 any      | 20 bytes        | CompressRule=9
1010 any      | Reserved        | CompressRule=10
1011 any      | Reserved        | CompressRule=11
11xx any      | Reserved for Multicast / Group Communications

TBD what to do with E / zero compression to T23 ? Reserve for another packet
type or just prohibit?..

TBD move tag len to tunnel format so 11 compression rules could be used?
rule does not need CBAR but can be simple CBOR: uint=copy N bytes from pkt,
bstr=add literal bytes, negative int for bits?
  TBD full BPF for bit fields? but this is not simple for constrained devices...
  - [Aug 2024] well, we target entire spectrum sizing from very constrained to
    very highload, so just offer several options: constrained could use
    something like GHC/LZF, more capable could accept BPF64 - so this should
    be one of BPF64 design goals

TBD split Connection Tag to separate Host ID, if IPnh provides us with it
- and for constrained sizes even Host IDs Sum instead of full pair
- 17.09.24 also add IPnh tunnel addresses, either in INIT or backends?
- 18.09.24 see fragmentation issues (for this day), so if ever ConnectionTag
  considered to be longer than 4 bytes, only alternatives are 8 and 12 bytes

  Поле TSN имеет то же значение, что и в SCTP - номер блока данных при передаче
  данных с подтверждением, имеет полный "виртуальный" размер 32 бита, и
  подчиняется тем же правилам арифметики по модулю 32, что и в TCP и в SCTP.

  Однако, поскольку тратить 4 байта на TSN в каждом чанке расточительно при
  очень малых размерах пакета, если опции с TSN вообще есть в пакете, то
  передается базовое TSN, а в самих опциях - только короткая дельта (они не
  могут быть опущены последовательной нумерации из-за ретрансмиссий при
  потерянныъ пакетах, т.е. "дырках").

  И кроме того, в ряде случаев 32-битный TSN Base подвергается дополнительной
  компрессии по методу, похожему на DCCP и протокол QUIC от Google.

2.4.1. TSN Base and it's compression.

TBD от сервера младшие биты про packet stamp:
 00 - fresh and timely answer to this packet id
 01 - packet stamp seen first time, but ACK delayed
 10 - ??? packet id non-first time, retransmitted
 11 - packet id reused for server next data
TBD вынести их в TSL? но тогда
TBD после смены адреса сервер шлёт меньше - защита от спуфа/DDoS
TBD Ack Delay в SACK ?

TBD Stateless Reset Token?
https://datatracker.ietf.org/doc/html/draft-trammell-plus-statefulness-04 :
4.3.1.  Authenticated Stop Signaling
   Additionally, the stop and stop confirmation signals could be
   designed to authenticate themselves.  Each endpoint could reveal a
   stop hash during the initial association, which is the result of a
   chosen cryptographic hash function applied to a stop token which that
   endpoint keeps secret.  An endpoint wishing to end the association
   then reveals the stop token, which can be verified both by the far
   endpoint and devices on path which have cached the stop hash to be
   authentic. 

HEARTBEAT MUST be at least twice per tv_sec bitwitdth interval - coz clock
drift

  В случае относительно низкой скорости (в пакетах) передачи данных, на низких
  MTU используется компрессия Transmission Sequence Number (TSN) Base -
  передача только одного или двух его младших байт из полных четырех. В отличие
  от QUIC, где номер пакета только монотонно растёт с нуля до 2^62 and don't
  wraps, у нас, в виду отсутствия места, классическая схема со всего лишь 32
  битами и их переиспользованием, поэтому соответствующий алгоритм компресии
  номера из QUIC не может быть применён в чистом виде. Для этого приходится
  применять вспомогательное средство из заголовка пакета, причем, поскольку
  передача данных может вестись одновременно по нескольким путям, а TSN are
  общие на всю ассоциацию, то Packet Counter не может быть использован,
  а только лишь Packet Stamp.

  Пусть "tick" - гранулярность Packet Stamp, предоставляемая тунгейтом
  (например, 1 миллисекунда или 125 мс), а Cumulative TSN Ack есть номер,
  ниже которого все TSN получены (возможны только дупликаты). Тогда, поскольку
  нет никакого вреда в том, чтобы передать TSN Base длиннее теоретически
  требовавшегося (кроме уменьшение доступного места в пакете), отправитель и
  получатель следуют нижеизложенным правилам.

  Отправитель:

  S1) все TSN с номерами, близкими к концу или началу на размер более меньшего
      участка + cwnd, передаются увеличенными. Например, TSN с 0x00000000 по
      0x00010001 и c 0xfffeffff по 0xffffffff передаются всегда как 4 байта, а
      все TSN c 0xhhhh0000 по 0xhhhh0101 и с 0xhhhhfeff по 0xhhhhffff - не менее
      чем 2 байта, если cwnd на соответствующие моменты составлял 1;
  S2) при каждом увеличении на следующий тик, первый пакет с ним (по каждому из
      путей) всегда передается с полным 4-байтным TSN;
  S3) в случае, если это ретрансмит какого-либо пакета не "как есть",
      а пересборкой из нескольких чанков, всегда MUST применяется 4-байтный TSN;
  S4) каждое определенное число пакетов с уменьшенным TSN Base передается на
      один размерный шаг больше: оно составляет каждый пакет из 16 для
      1-байтных TSN Base и каждые 1024 для 2-байтных - for simplicity,
      implementations MAY test if TSN divisble by 16 for 2-byte and by 1024
      for 4-byte [Rationale: packet loss ~3% дает примерно каждый 32-й пакет, на
      случай, если потеряны именно они, увеличим число];
  S5) наконец, применяется алгоритм из QUIC: из TSN Base готовящегося к отправке
      пакета вычитается текущий Cumulative TSN Ack получателя, и число байт
      TSN Base должно вмещать более чем два этих числа. Note that comparison
      here is strict: difference 127 is still 1 byte, but 128 raises 2 bytes. 

  Получатель же, в случае получения неполного TSN Base, применяет
  модифицированную процедуру из DCCP с псевдокодом:

   procedure Extend_Sequence_Number(S, REF, width)
      /* S is a width-bit (8 or 16) sequence number from the packet header.
       * REF is the relevant full 32-bit reference sequence number 
       */
      Set REF_low := low width bits of REF
      Set REF_hi := high (32-width) bits of REF
      If REF_low (<) S           /* circular comparison mod 2^width */
            and S |<| REF_low,   /* conventional, non-circular comparison */
         Return (( (REF_hi + 1) mod 2^(32-width) ) << width) | S
      Otherwise, if S (<) REF_low and REF_low |<| S,
         Return (( (REF_hi - 1) mod 2^(32-width) ) << width) | S
      Otherwise,
         Return (REF_hi << width) | S

  Основной проблемой здесь является нахождение полного 32-битного REF, на
  основе которого вычисляется полный TSN Base текущего пакета. DCCP and QUIC
  используют в качестве него номер самого последнего полученного пакета.
  В DCCP проблема маловероятна к достижимости в реальном мире ввиду широкого
  размера номера: 2^23 пакетов стандартного Ethernet MTU размера 1500 байт
  потребуют 100 Gbit/s, что является труднодостижимым размером cwnd даже
  спустя 15 лет после опубликования спецификации DCCP. QUIC же has design flaw
  и игнорирует проблему, неявным образом полагаясь на TLS в части replay
  attacks and out-of-order packets - в случае ошибочного определения номера
  пакета, используемого для IV/nonce [RFC 9001, Section 5.3, 5.5], будет получен
  неверный AEAD и пакет будет отброшен, но с криптографическими затратами. Это
  не подходит для протокола, который, ввиду поддержки ограниченный устройств,
  имеет режим работы без шифрования, а также производит шифрование пакетов на
  более низком уровне, не зависящем от TSN Base.

  Суть проблемы: предположим, что мы получаем пакет из прошлого с 1-байтным
  TSN Base, который вполне укладывается в окно с соседним "свежим" 1-байтным
  TSN Base. В этом случае он будет декодирован в неверный номер, и произойдет
  повреждение потока данных. Вариант включения полного TSN Base в подпись
  передаваемого пакета (без передачи его самого) позволил бы избежать проблемы
  способом QUIC, но потребовал бы криптографических затрат, что неприемлемо
  для ограниченных устройств (можно приравнивать к DoS-атаке).

  Предположим, для простоты рассуждений, что мы имеем только сокращенные
  в 8 бит и полные в 16 бит, считая каждое полученное 16-битной значение
  референсным. Тогда процедура Extend_Sequence_Number будет давать корректные
  результаты для значений в интервале [-128..+127] от референсного. Тогда нам
  необходимо отсеять значения от -128 и ниже. Отсюда вытекает, как минимум,
  что кратность передачи референсных значений должна быть делителем 128, т.е.
  составлять 64 или менее. Далее, правило S5 гарантирует нам, что уменьшенных
  TSN Base будет отправлено менее 128 от нашего Cumulative TSN Ack, поэтому
  можно отсекать все пакеты с таймштампом строго меньшим, чем был у пакета
  с TSN, равным текущему Cumulative TSN Ack, но здесь возникает subtle
  problem: как быть, если пакет из прошлого приходит с тем же самым tick, что
  у Cumulative TSN Ack, вследствие плохой гранулярности таймштампов?

  Рассмотрим гипотетическую ситуацию в сети, возникшую на линке с 3 битами на
  доли секунды, т.е. таймером 8 Гц, в стабильных до того момента условиях при
  cwnd=254:

               Sender                                     Receiver
                  |                                           |
                  |  S=123 from tick 0, will also dup ------> | decode OK,
  -- tick 1/8 ----+                                           | Nagle timer
                  |  S=124 -- will also dup ----------------> | started
                  |  S=125..128 ----------------------------> | 
                  |  S=125 -- DUP IN NET ---,        .------- | send ACK
                  |  S=126 -- DUP IN NET ---.\      /         |
                  |  S=127 -- DUP IN NET -----\    /          |
                  |  S=128 now Cumul Ack <-----\--'           |
                  |  S=129 ----.                \             |
  -- tick 2/8 ----+             \                \            |
                  |  S=130..253  \                \           |
                  |   cwnd allows >-- (X) LOST!    \          |
                  |     sending  /                  \         |
                  |                                  \        |
                  | TSN=254 Reference  ---------------\-----> | OK, Nagle
                  |   S=255 last allowed by S5 --------\----> | decode OK
                  | (T3-rtx fires, cwnd halves, stop)   `---> | ???

  Пусть на рисунке отправитель имел последний подтвержденный TSN=128, и окно
  позволило отправить ему пакеты с номерами по 255 включительно, из которых
  TSN=254 имел полную ширину и был референсным, а пакеты со 129 по 253 были
  потеряны. Теперь, вследствие проблем в сети или действий атакующего, после
  пакетов 254 и 255 получателю прибывают дубликаты пакетов с TSN=123 по
  TSN=127. Пакет с TSN=123 был из другого тика, 0, меньше, чем тик=1
  последнего подтвержденного пакета с TSN=128, и был отброшен. Применим
  процедуру Extend_Sequence_Number(S, 254, 8) для S=124..127.

  Имеем REF_hi=0, REF_low = 254, для аргументов следует:

  S=124: REF_low (<) S: true
         S |<| REF_low: true
	               ---> return ((0+1)<<8) | 124 => TSN=380
  S=125: REF_low (<) S:true
         S |<| REF_low: true
	               ---> return ((0+1)<<8) | 125 => TSN=381
  S=126: REF_low (<) S: false
         S (<) REF_low: false
                       ---> return ( (0) <<8) | 126 => TSN=126
  S=127: REF_low (<) S: false
         S (<) REF_low: true
	 REF_low |<| S: false
                       ---> return ( (0) <<8) | 127 => TSN=127

  На этом примере мы видим, что, если пакеты c S=124 и S=125 отправлялись
  в тот же тик, они не будут отброшены сравнением строгого неравенства по
  времени, в отличие от S=123. Не помогло бы и сравнение "меньше или равно"
  с TSN=128, поскольку, как мы видим, если S=129 отправляется в тот же тик, он
  вполне ожидаем и валиден. Правило S2 позволило бы исключить из этого списка
  пакет с TSN=124 как первый в тик (он был бы передан референсным), но всё еще
  остается проблема со 125-м. Нельзя здесь и иметь ожидания по поводу размера
  окна: в TSN=128 отправитель мог передать LINK_INFO с большим cwnd, так что
  вполне ожидаемы TSN вплоть до 382.

  Из других полей имеем решение: получателю сохранять так же и Packet Counter
  пакета, на который отправлялся Cumulative TSN Ack, и сравнивать с ним пакеты
  в том же тике, что и Cumulative TSN Ack - тогда более старые могут быть
  отброшены. Здесь следует подчеркнуть, что Packet Counter является отдельным
  счетчиком для каждого линка, а не глобальным, поэтому, будучи вполне
  применимым в случае единственного пути, вызывает вопросы. Однако эта
  проблема вполне разрешима, если считать, что дубликаты пакетов в сети могут
  появиться только по тому же самому пути/паре адресов, на которой они
  изначально были переданы. Отсюда, в том числе, и вытекает правило S3: если
  ретрансмиты происходят по другому пути, в них должен быть полный TSN, и
  Packet Counter другого пути будет в данном случае неважен.

  Note: it's HALF of Packet Counter per tick permitted! as circular comparison

  Receiver Path 1                Sender                 Receiver Path 2
         |           ...            |                          |
         |                          |---- S=10 --------------> |
         |--- SACK=10 ------------> |                          |
 ms=125 -+                          |                          +- tick 1/8
         | <-------------- TSN=11 --|                          |
         | <-------------- TSN=12 --|                          |
         |                          |---- S=13 --------------> |
         |--- SACK=12 ------------> |                          |
         |                          | <------------- SACK=13 --|
 ms=126 -+                          |                          |
         | <-------------- TSN=14 --|                          |
         | <-------------- TSN=15 --|                          |
         |                          |---- S=16 --.             |
         |--- SACK=15 ------------> |             \            |
         |                          |              \           |
         | <-------------- TSN=17 --|               ,          |
         | <-------------- TSN=18 --|               |          |
 ms=127 -+                          |---- S=19 --------X       | LOST!
         |--- SACK=15,17-18 ------> |               |          |
         |                          |               |          |
         | <-------------- TSN=20 --|               |          |
         | <-------------- TSN=21 --|               |          |
         |                          |---- S=22 --------X       | LOST!
 ms=128 -+                          |               |          |
         |--- SACK=15,17-18,        |               |          |
         |            20-21 ------> |               |          |
         |                          |               |          |
         | <-------------- TSN=23 --|               |          |
         | <-------------- TSN=24 --|               |          |
 ms=129 -+                          |               |          |
         |                          |---- S=25 --------X       | LOST!
         |--- SACK=15,17-18,        |               |          |
         |            20-21, -----> | Fast Recovery |          |
         |            23-24         | starts        |          |
 ms=130 -+                          |               |          |
         |                          |---- S=16 --------X       | LOST!
         | <-------------- TSN=26 --|               |          |
         | <-------------- TSN=27 --|               |          |
 ms=131 -+                          |               `          |
         |--- SACK=15,17-18,        |                \         |
         |            20-21,        | Fast Recovery   \        |
         |            23-24, -----> | did not help?    \       |
         |            26-27         | opportunistic     \      |
         |                          | try to switch      \     |
         | <-------------- TSN=16 --| path                \    |
         | <-------------- TSN=19 --|                      |   |
 ms=132 -+                          |                      |   |
         |--- SACK=21,23-24,        |                      |   |
         |            26-27 ------> |                      |   |
         |                          |                      |   |
         | <-------------- TSN=22 --|                      |   |
         | <-------------- TSN=25 --|                      |   |
 ms=133 -+                          |                      |   |
         |--- SACK=27 ------------> |                      |   |
         |                          |                      |   |
         ... time passes, new Reference TSN is possible... | ...                      ...
 ms=249 -+                          |                      `-> | ???

TBD хранить advancing Cumul номер для каждого пути, применять S5 от 
этих цифр, кроме общего - тогда 10 в примере отбросится как в простом примере
выше ??? какой брать за референсный? неужто последний приходивший в этом пути
либо его Cumul?

RFC quotes:
   To provide an order among notifications for the client, the server
   sets the value of the Observe Option in each notification to the 24
   least significant bits of a strictly increasing sequence number.  An
   incoming notification was sent more recently than the freshest
   notification so far when one of the following conditions is met:

                      (V1 < V2 and V2 - V1 < 2^23) or
                      (V1 > V2 and V1 - V2 > 2^23) or
                      (T2 > T1 + 128 seconds)

   where V1 is the value of the Observe Option in the freshest
   notification so far, V2 is the value of the Observe Option in the
   incoming notification, T1 is a client-local timestamp for the
   freshest notification so far, and T2 is a client-local timestamp for
   the incoming notification.

   Design Note:  The first two conditions verify that V1 is less than V2
      in 24-bit serial number arithmetic [RFC1982].  The third condition
      ensures that if the server is generating serial numbers based on a
      local clock, the time elapsed between the two incoming messages is
      not so large that the difference between V1 and V2 has become
      larger than the largest integer that it is meaningful to add to a
      24-bit serial number; in other words, after 128 seconds have
      elapsed without any notification, a client does not need to check
      the sequence numbers to assume that an incoming notification was
      sent more recently than the freshest notification it has received
      so far.

      The duration of 128 seconds was chosen as a nice round number
      greater than MAX_LATENCY (Section 4.8.2 of RFC 7252 [RFC7252]).

   of each notification it sends to the 24 least significant bits of a
   strictly increasing sequence number.  The sequence number MAY start
   at any value and MUST NOT increase so fast that it increases by more
   than 2^23 within less than 256 seconds.

   Implementation Note:  A simple implementation that satisfies the
      requirements is to obtain a timestamp from a local clock.  The
      sequence number then is the timestamp in ticks, where 1 tick =
      (256 seconds)/(2^23) = 30.52 microseconds.  It is not necessary
      that the clock reflects the current time/date.

      Another valid implementation is to store a 24-bit unsigned integer
      variable per resource and increment this variable each time the
      resource undergoes a change of state (provided that the resource
      changes its state less than 2^23 times in the first 256 seconds
      after every state change).  This removes the need to update the
      value of the Observe Option on retransmission when the resource
      state did not change.

   Design Note:  The choice of a 24-bit option value and a time span of
      256 seconds theoretically allows for a notification rate of up to
      65536 notifications per second.  Constrained nodes often have
      rather imprecise clocks, though, and inaccuracies of the client
      and server side may cancel out or add in effect.  Therefore, the
      maximum notification rate is reduced to 32768 notifications per
      second.  This is still well beyond the highest known design
      objective of around 1 kHz (most CoAP applications will be several
      orders of magnitude below that) but allows total clock
      inaccuracies of up to -50/+100%.

RFC 1323:
  The dotted line marks a pause (60 time units long) in which A had
      nothing to send.  Note that this pause inflates the RTT which B
      could infer from receiving TSecr=131 in data segment C.  Thus, in
      one-way data flows, RTTM in the reverse direction measures a value
      that is inflated by gaps in sending data.  However, the following
      rule prevents a resulting inflation of the measured RTT:

           A TSecr value received in a segment is used to update the
           averaged RTT measurement only if the segment acknowledges
           some new data, i.e., only if it advances the left edge of the
           send window.

      Since TCP B is not sending data, the data segment C does not
      acknowledge any new data when it arrives at B.  Thus, the inflated
      RTTM measurement is not used to update B's RTTM measurement.

              To make this more quantitative, any clock faster than 1
              tick/sec will reject old duplicate segments for link
              speeds of ~8 Gbps.  A 1ms timestamp clock will work at
              link speeds up to 8 Tbps (8*10**12) bps!

         (b)  The timestamp clock must not be "too fast".

              Its recycling time must be greater than MSL seconds.
              Since the clock (timestamp) is 32 bits and the worst-case
              MSL is 255 seconds, the maximum acceptable clock frequency
              is one tick every 59 ns.

              However, it is desirable to establish a much longer
              recycle period, in order to handle outdated timestamps on
              idle connections (see Section 4.2.3), and to relax the MSL
              requirement for preventing sequence number wrap-around.
              With a 1 ms timestamp clock, the 32-bit timestamp will
              wrap its sign bit in 24.8 days.  Thus, it will reject old
              duplicates on the same connection if MSL is 24.8 days or
              less.  This appears to be a very safe figure; an MSL of
              24.8 days or longer can probably be assumed by the gateway
              system without requiring precise MSL enforcement by the
              TTL value in the IP layer.
TBD 
   other uses of the Timestamps option, such as the Eifel mechanism
   ([RFC3522], [RFC4015])

TBD rule S3 means fragmentation on retransmit if shortened TSN - define 1-3
byte SACK to fill such cases? or ECNE_CWR ?
- Compression Rule of e.g. (0x64, 20 pkt bytes, 3-TSL ECNE bytes) (hardcode TSL cond)
- needs "to which pkt it is reply" in Header and synthetic SACK from ECNE_CWR

TODO RFC 3095 ROHC for stride
4.5.2
   Note that the decompressor follows the procedure described in the
   previous section, except that in R-mode it MUST ACK each header
   received with a succeeding CRC (see also section 5.5).

      Note: The clock resolution of the compressor or decompressor can
      be worse than TIME_STRIDE, in which case the difference, i.e.,
      actual resolution - TIME_STRIDE, is treated as additional jitter
      in the calculation of k.

TODO

2.4.2. Chunks.

  Далее в пакете идёт основная часть - chunk'и, они же опции. Они имеют формат
  TLV "тип-длина-значение" в компрессированном виде. Опции расположены в пакете
  в сортированном виде, и в типе, т.е. номере опции, на самом деле пишется
  дельта от предыдущей. В начале пакета текущее значение равно нулю. 

  Формат одной опции в простейшем виде напоминает схему из CoAP:
	
       0   1   2   3   4   5   6   7
     +---------------+---------------+
     |               |               |
     |  Option Delta | Option Length |   1 byte
     |               |               |
     +---------------+---------------+
     \                               \
     /         Option Length         /   0-1 bytes
     \          (extended)           \
     +-------------------------------+
     \                               \
     /                               /
     \                               \
     /         Option Value          /   0 or more bytes
     \                               \
     /                               /
     \                               \
     +-------------------------------+

  Для дельты здесь допустимы значения 0-11, а для длины имеются специальные
  значения:

    0-14 - непосредственно значение
    14   - в следующем байте значение минус 14
    15   - Reserved

  Таким образом, например, для опций 5, 6 и 8 будут на самом деле записаны
  типы 5, 1 и 2 в дельтах, что в типичном случае нескольких опций в пакете
  при их достаточно короткой длине позволяет укладывать в 1 байт и тип, и 
  длину даже тогда, когда номера последних опций выходят за первые 12 (если
  есть промежуточные значения). Разрешено несколько одинаковых опций подряд,
  тогда все они (кроме, может быть, первой) будут иметь 0 в дельте.

  Такое ограничение на длину опции - а данные пользователя передаются тоже в
  опциях - и обуславливает расчет на работу короткими пакетами, когда длина
  одного блока данных значительно меньше типичного пакета в Internet
  (1500 байт). Предполагается, что при нужде столь больших пакетов место
  будет заполняться одновременной передачей по нескольким потокам. Если и
  этого недостаточно, планируется опция для описания неограниченной длины в
  Payload/Padding части пакета.

TBD нужна ли такая опция? будут ли бэкенды со столь большими пакетами?

  По значению Delta / Length оба 15, т.е. байту 0xff (но не в любом месте, а
  ожидаемом начале опции), обработка опций прекращается. В оставшемся месте
  могут быть размещены, при необходимости, контрольные суммы или padding для
  шифрования.

  Поскольку прямое заимствование формата CoAP требовало был еще 1 байт для
  Option Delta Extended, это получилось бы до 270 опций, и то это дельты, т.е.
  самих значений возможно еще больше, но практика показывает, что столько на
  практике не используется - даже в "большом" SCTP отведен 1 байт на
  абсолютный номер. При этом такой заголовок занимал бы до 3 байт, позволяя
  длину не более 269, что на пакетах "обычного" Интернета слишком мало.
  Поэтому для двухбайтных заголовков применена другая схема, позволяющая более
  широкое поле длины:

       0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 1   1 | Chunk Delta, 0-30 |   Chunk Length, 9 bit (511 max)   |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Опции - аналог chunks в SCTP, но требование сортировки их в пакете налагает
  ограничения на нумерацию: если SCTP может потребовать расположение одних
  chunks после других, то здесь придется назначать номера специфичным образом.
  Ситуацию усугубляет нужда экономии каждого байта, поэтому приходится
  разделять номера среди первых 14 и остальных с целью экономии байта на
  дельту для случая первой опции в пакете, и идти на исключения в виде
  разных форматов одного и того же номера опции от сервера и клиента, чтобы
  уложить их в один и тот же номер. Поэтому нумерация может казаться странной:

     ID Val/Mnemonic  Opt Chunk Type
     -----            ----------
     0       NUL ^@ - SACK: Selective Acknowledgement
     1       SOH ^A - AUTH_CHK: Authenticate / Checksum this very packet
     2       STX ^B - BYTESTREAM_CHANNEL: Bytestream Channel Operations
     3       ETX ^C - CONFIG_ATOM: String/Address/Path Config Stream Data
     4       EOT ^D - DATA: User Payload Data
     5       ENQ ^E - ECHO: Heartbeat Acknowledgement / State Cookie
     6       ACK ^F - ??? FORWARD_TSN? or better other num
     7       BEL ^G - 
     8       BS  ^H - HEARTBEAT: Heartbeat Request
     9       HT  ^I - INTERCHUNK_STREAM_CONTROL: TSN Auth/Fwd/Window/Compress 
     10 0x0a LF  ^J - COOKIE_ACK: Cookie Acknowledgement
     11 0x0b VT  ^K - KEXCH_CRYPT: Crypto / Key Exchange Stream Data
     12 0x0c FF  ^L - LINK_INFO: Measured SRTT/RTTVAR/MTU/cwnd/etc. inform
     13 0x0d CR  ^M - MORE_DATA: Server Has Bytes Available to Request
     14 0x0e SO  ^N - ERROR:  Operation Error [Mnem: 0xe]
     15 0x0f SI  ^O - SHUTDOWN: Shutdown [Mnem: FIN]
     16 0x10 DLE ^P - SHUTDOWN_ACK: Shutdown Acknowledgement
     17 0x11 XON ^Q - QUEUE_READ_ACK: Blocks processed by ULP [Mnem: MQTT ^QoS]
     18 0x12 DC2 ^R - ABORT: Abort association [Mnem: ^Reset] 
     19 0x13 XOF ^S - Congestion ECNE/CWR
     20 0x14 DC4 ^T - TIMESTAMP: Time at Sender & Echo Time of Receiver
     21 0x15 NAK ^U - Reserved
     22 0x16 SYN ^V - Reserved
     23 0x17 ETB ^W - Reserved
     24 0x18 CAN ^X - CANCEL_BLOCK: don't finish transfer of block TBD
     25 0x19 EM  ^Y - SHUTDOWN_COMPLETE: Shutdown Complete
     26 0x1a SUB ^Z - Reserved
     27 0x1b ESC ^[ - Reserved
     28 0x1c FS  ^\ - ??? FRAGMENTS?
     29 0x1d GS  ^] - Reserved
     30 0x1e RS  ^^ - Reserved
     31 0x1f US  ^_ - ??TBD MTU_PROBE ?

      00 -  Stop processing this SCTP packet and discard it, do not
            process any further chunks within it.

      01 -  Stop processing this SCTP packet and discard it, do not
            process any further chunks within it, and report the
            unrecognized chunk in an 'Unrecognized Chunk Type'.

      10 -  Skip this chunk and continue processing.

      11 -  Skip this chunk and continue processing, but report in an
            ERROR chunk using the 'Unrecognized Chunk Type' cause of
            error.

-- variant 19

вообще всё переделать начисто, 3 или более разных number space: для
user TSN chunks, internal streams TSN chunks и обычных опций - тех мб тоже
разделить по типу stop/report (в SCTP) ниже, дальше при двухбайтном формате -
выбираем Хаффманом, и до полных 2 Кб выходит

 long            7   8            15 
 1 1 . 0 s s s s s . L L L L L L L L |                  - простые опции
 1 1 . 1 0 i i i L . L L L L L L L L | D D D D D B E S  - internal streams
 1 1 . 1 1 0 U U L . L L L L L L L L | L L D D D B E S  - user data streams
 1 1 . 1 1 1 x x x                                      - special values,
                                   e.g. curInternal +=8, curUserData += 4 

однобайтные 0..191, 10 значений по 19 байт длины + 2 специальных
TBD юзерские не могут быть короткие, так что можно 1..19 на 4..22
в начале имеем curSimple:=0, curInternal:=-1, curUserData:=-1
0    - та же опция, что была
1..7 - curSimple += delta
8    - curInternal += 1  <- 8..9 тоже к curSimple, если в пакете нет TSN Base
9    - curUserData += 1  TBD сразу проблема с выбором channel или block 1-го
TBD если как-то несколько битов в заголовке выкроить
если уменьшить TSN Base до 29 бит, тогда и FRAGMENTS переделать, см. там
Flags 3 бита: два 00, 01 curInternal++, 10 curUserData++, 11 extra flags byte
флаг IM: если от сервера more_data=true по пакету, то Immediate_SACK else
MORE_DATA, от клиента только как Immediate_SACK

if prev=simple and cur=TSN then curSimple++ # для ECHO+DATA после INIT
то же самое для iTSN, но только если это не самый первый simple-блок пакета

TODO 8/9 for +1 become longer than in zero? inconsistent
TBD variant: only one TSN chunk, last byte is |i/U d|T D|B E S|, TSN Base now
is 32 bit again, but low 2 bits are flags: AUTH and IM, even in compressed TSL
TBD for some data be possible to not AUTH, it's simpler to have just one DATA opt

0  - SACK                      0 - ATOM_CONFIG               0 - USER_MESSAGE
1  - AUTH                      1 - KEXCH_CRYPT               1 - USER_CHANNEL
2  - ECNE_CWR                  2 - INTERCHUNK_STREAM_CONTROL
3  - LINK_INFO                 3 - QUEUE_READ_ACK
4  - FORWARD_TSN ??? or in internal streams?
5  - FRAGMENTS
6  - TIMESTAMP
7  - COOKIE_ACK
8  - ECHO
9  - Reserved
10 - MORE_DATA # reachable from FRAGMENTS/LINK_INFO or by bit flag if TSN Base
11 - HEARTBEAT
12 - ERROR     # reachable from TIMESTAMP
13 - SHUTDOWN_COMPLETE
15 - SHUTDOWN / SHUTDOWN_ACK
18 - ABORT
21 - NAK # compress/HMAC fail / stream window full
24 - CANCEL_BLOCK # ABANDON_BLOCKS
31 - MTU_PROBE

TBD перенести компрессию на уровень TSN - по порогу длины 1426
-> нет, вместо этого контейнер опций
 * FB для линка, следом VarInt15 для длины - фактически под ng_pred1
 * FD для общего, где 3 бита - номер компрессора, 1 бит - добавить в словарь как
   uncompressed (см. ng_deflate) и 12 бит длины; внутри первые 1-2 байта - в
   формате PPP Protocol, где кодируем 13 бит преобразованного заголовка
   первого U-чанка 
   TBD как именно, чтоб компрессия 0x00xx могла в 1 байт по PPP срабатывать?
     заставить DDD=0 всегда?
       -> кстати для переупорядочивания пригодится
   TBD just update dictionary ведь тоже использует PPP Protocol в него, в
     нашем случае сфабрикованный? а в pred1 без него
   Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF
   and neither 0xFD nor 0xFB are compressed.  Other PPP packets are
   always sent uncompressed.  Control packets are infrequent and should
   not be compressed for robustness.
   -> this leaves only 11 bits (Hi LSB must be 0), and minus two values (0xfb/0xfd)
   вариант: на длину внутреннего чанка их
   TBD Bitmap Ranges по номерам TSN ?
   -> no, deflate outputs CRC-32 only at end of stream, not at block, so this
   must be checksum
     -> CRC-24 by RFC 4880

! we can't use I/U delta in length part - TSNs are independent from packet
(cf. options), e.g. after retransmit on a path with different MTU

TBD what if make compression a "packet" (it's NAK'ed all once, anyway), e.g.
making a virtual "links" mapped to physical links (paths) ?

-- variant 20

say 0b10110 = 22

       0   1   2   3   4   5   6   7
     +---+---+---+---+---+---+---+---+...
     | Length - 1, 0..22 |Opt. Delta | Option Data
     +---+---+---+---+---+---+---+---+...

       0   1   2   3   4   5   6   7
     +---+---+---+---+---+---+---+---+...
     | 1   0   1   1   1 |Auth Length|
     +---+---+---+---+---+---+---+---+...

short chunks (0xC0..CF):

       0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...
     | 1   1   0   0 |   Chunk Length    |Chunk Type 0-13|Beg|End|Spe|
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...

middle options (0xD0..DF):

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 0 1|Opt Delta|Option Length| Option Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

long options (0xE0..E7):

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 1 0 0|Option Delta |     Option Length     | Option Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

long chunks (0xE8..EF):

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 1 0 1|      Chunk Length     |ChuType|B|E|S|     <- hey, here's 12 bit!
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

ending of both short and long chunks when Auth Key set (means B=1 E=0):

       0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
  ...+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...
   Length| 1   1   1 |  Chunk Type   |      Auth Key ID          |Spe|
  ...+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...

TODO as options 4096 now, compressed in option instead of separate parser type

inside compressed container:

       0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...
     |        Chunk Length + UserChunkType * 1170        |Beg|End|Spe|
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...

TBD our max size is 4096, thus should be 4096/3 = 1365
inside compressed container when Auth Key set (means B=1 E=0):

       0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+...
     |         Chunk Length + 7020          |UsrChTyp|     Auth Key ID    |Sp|
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+...

TBD make it B flag when Auth Key ID, for intermediate key change before ending (instead of SSN records)?

F0...F7 = Flags, or Internal Padding, if all-zero
F8 - Option Delta += 128

then as in variant 19

TBD fragmentation problem - no need to AUTH every frag, but overall may has
need, have packet sections?
 -> see frag variant Packet 2.1

TBD begin/end AUTH directly in format instead of separate option?

TBD FORWARD_TSN bundling problem - skipped and unskipped Partial Reliability blocks may have same TSN
TBD large packet, same stream, bundle end of one message with beginning of next or several msgs
TBD both solvable, real problem is NAK due to window for *part* of TSN
-> make new bitmap opt instead of TSN Delta in each? also flags in it
TBD if return to TSN per chunk, then fragments - it allows 14 bits, but above only 11
-> make long format always with Auth Key, 3 bits 0b111 now avail for length,
   and make middle chunks by taking bit from long options:

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 1 0 0 0|OptionDelta|     Option Length     | Option Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 1 0 0 1|      Chunk Length     |ChuType|B|E|S|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 0 1|        Chunk Length       |ChuType|Auth Key ID|B|E|S|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

swap them?.. use 0xf0 range?..
two packet formats, short and long?..

таки вынести Auth Key ID into STREAM_CONTROL ? then problem with non-delayed
delivery before Cumulative TSN Ack
put a bit flag? where? direclty or common packet flags?
mb see what's for rekey in TLS? no, better in SSH
still need Key ID because some bay be unauthed?

TBD what if put Auth Key ID - not in first chunk, but in LAST ? as last byte
- this would require buffering of all (probably 256 K) before start hashing
- then as first byte of second chunk?

TBD why Auth in every chunk? could be global for packet, as Immediate_SACK
- because some may be un-authed as requested by user

TBD inherit key for A bit also from Shared Key ID, as in AUTH opt ?

TBD return to put chunks in their option to free some bits? 32 vs 23 is not very much saving

giant chunks (0xC0..DF):

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 0|        Chunk Length       |ChuType|B|E|S| equal to option where A=0
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TBD may be move this kostyl to fragments? middle options should be longer

middle options (0xE0..EF):

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 1 0|Opt Delta|Option Length| Option Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

long options (0xF0..F7):

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 1 1 0|Option Delta |     Option Length     | Option Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

chunk option start with byte with Auth and other flag, and 4 bit key if has HMAC

       0   1   2   3   4   5   6   7
     +---+---+---+---+---+---+---+---+...
     |   Chunk Type  |Aut|Beg|End|Spc| Data
     +---+---+---+---+---+---+---+---+...

       0   1   2   3   4   5   6   7
     +---+---+---+---+---+---+---+---+...
     |   Chunk Type  | 0 |Beg|End|Spc | Data
     +---+---+---+---+---+---+---+---+...

       0   1   2   3   4   5   6   7
     +---+---+---+---+---+---+---+---+...
     |   Chunk Type  | 1 |KeyId-1|Spc| Data
     +---+---+---+---+---+---+---+---+...

     ID Val/Mnemonic  Opt Chunk Type
     -----            ----------
     0       NUL ^@ - TIMESTAMP: Time @ Sender & Echo Time of Receiver
     1       SOH ^A - TSN_HEADER: Flags and numbers of subsequent TSNs
     2       STX ^B - MORE_DATA: Server Has Bytes Available to Request
     3       ETX ^C - ??? AUTH end?
     4       EOT ^D - DATA: Internal streams and User Payload TSN Data
     5       ENQ ^E - ECHO: Heartbeat Acknowledgement / State Cookie
     6       ACK ^F - SACK: Selective Acknowledgement
     7       BEL ^G - FRAGMENTS: Recovery TSN after MTU fall
     8       BS  ^H - HEARTBEAT: Heartbeat Request
     9       HT  ^I - 
     10 0x0a LF  ^J - COOKIE_ACK: Cookie Acknowledgement
     11 0x0b VT  ^K - 
     12 0x0c FF  ^L - LINK_INFO: Measured SRTT/RTTVAR/MTU/cwnd/etc. inform
     13 0x0d CR  ^M - 
     14 0x0e SO  ^N - ERROR:  Operation Error [Mnem: 0xe]
     15 0x0f SI  ^O - SHUTDOWN: Shutdown [Mnem: FIN]
     16 0x10 DLE ^P - SHUTDOWN_ACK: Shutdown Acknowledgement
     17 0x11 XON ^Q -  [Mnem: MQTT ^QoS]
     18 0x12 DC2 ^R - ABORT: Abort association [Mnem: ^Reset] 
     19 0x13 XOF ^S - ECNE_CWR: Congestion Packet Vector
     20 0x14 DC4 ^T - 
     21 0x15 NAK ^U - NAK: compress/HMAC fail / stream window full
     22 0x16 SYN ^V - Reserved
     23 0x17 ETB ^W - Reserved
     24 0x18 CAN ^X - CANCEL_TSN: Forward Cumulative Ack and skip TSNs
     25 0x19 EM  ^Y - SHUTDOWN_COMPLETE: Shutdown Complete
     26 0x1a SUB ^Z - COMPRESSED_DATA: [Mnem: 26 for PPP Deflate]
     27 0x1b ESC ^[ - Reserved
     28 0x1c FS  ^\ - 
     29 0x1d GS  ^] - Reserved
     30 0x1e RS  ^^ - Reserved
     31 0x1f US  ^_ - MTU_PROBE

TBD TSN_HEADER - use just between-deltas instead of to-base deltas?
0FFDDDDD - 2 bits flags, 5 delta? do we need local flags?
1xxxxxxx - 7 bit global flags

   There is low number of options, and timestamp could be before each
   TSN chunk, so abandon option delta at all:

short options (0x00..BF):

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+...
     |Length<23|Opt<8| Option Data
     +-+-+-+-+-+-+-+-+...

middle options (0xC0..DF):

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 0|Option<32| Option Length | Option Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

long options (0xE0..EF):

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1 1 1 0|     Option Length     | Option Number | Option Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

for compressed, make it always authenticated? to check correctness

TBD 09.11.24 from perspective of retransmiting fragments after MTU drop, looks
like every TSN must have it's *own* *options* inside - if it has timestamp, or
authenticated, or these are inherited from packet one's

-- /variant 20

TBD with ABES, still has header checking problem: dispatch result like
"length/PPID" should be presented to user as early as possible (for decision),
but HMAC will be at end of entire block, needing to buffer or blindly trust...


  Во время установления и завершения ассоциации фиксированный заголовок
  трактуется особенным образом, поэтому они рассмотрены в отдельных
  разделах. Форматы опций при нормальной работе описаны в разделе 4.
  Во время установления соединения первый пакет, и ответ на него, имеет
  другой формат - без опций:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|R|E|                          0                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .    0/1/2/4 байта - Transmission Sequence Number (TSN) Base    .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /           INIT or INIT ACK data till end of packet            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Поскольку во время установления соединения Verification Tag еще неизвестен
  и должен быть равен нулю, а опции INIT и INIT ACK, если бы они были опциями,
  всё равно подвергались бы требованию того, что они ДОЛЖНЫ быть единственными
  опциями в пакете, было бы неразумным тратить 2 байта на номер опции и её
  длину при том, что (в случае сервера) желательно увеличить длину Cookie из
  криптографических соображений. Поэтому правило простое:

    * если Connection Verification Tag ненулевой, формат пакета - с опциями
    * если Connection Verification Tag равен нулю, формат пакета - INIT/ACK

  Во время установления соединения первый пакет от клиента всегда имеет
  Verification Tag нулевым, означая INIT, но сервер может ответить как
  INIT ACK, так и ошибкой. В случае ответа ошибкой применяется обычный формат
  пакета, т.е. Verification Tag должен быть ненулевым, и в принципе может
  иметь любое значение, но по соглашению, РЕКОМЕНДУЕТСЯ в этом случае делать
  его тоже целиком нулевым, кроме единичного бита E, как на диаграмме. Это же
  рекомендовано бэкендам, для удобства их реализации и компрессии - нулевой
  Verification Tag бэкендам РЕКОМЕНДОВАНО "компрессировать" битовым флагом,
  чтобы не передавать нули в пакете, и таким образом расширить MTU первого
  пакета (длину INIT-данных) еще на 3-4 байта.

TODO 100000... for ABORT packet, and echo Tag of Sender as first bytes, or
else in Host-to-Host (no ports) tunnel it would not be possible to match which
association caused Reset

2.5. Common used data types.

  PFloat7 - Positive Float in 7 bit
  Septinovile - 6 bit, 7*9 + 0

2.5.6. Pyramint5, Pyramint6, Pyramint7 and Pyramint8.

исходная идея:
TBD вариант Хаффмана 1-байтным:
0aaaaaaa - 0..127, unit=1
10bbbbbb - 0..63,  unit=128   -> max 8192
110ccccc - 0..31,  unit=8192  -> max 256 K
1110dddd - 0..15,  unit=256 K -> max 4 M
11110eee - 0..7,   unit=4 M   -> max 32 M
111110ff - 0..3,   unit=32 M  -> max 128 M
1111110g - 0..1,   unit=128 M -> max 256 M
в 7 битах будет до 2 М, в 6 битах аналог даст 32768

раскрываем:

   This is a variation of static Huffman encoding of unsigned integer, in
   a "pyramid" way, where first (most wide) is exact value, and each next level
   is in "units" of next power of two after maximal value of previous level. Levels are
   encoded as bit prefixes 0, 10, 110, etc.

   For example, Pyramint5 is

   * 0aaaa - unit is 1, so values 00000 to 01111 are 0..15
   * 10bbb - now unit is 16, 15+1, and bbb=000 means 16, bbb=001 means 32,
             so e.g. overall Pyramint5 value 10001 means 32, and maximal value
	     at this level, bbb=111 and overall Pyramint5 10111 - is 128.
   * 110cc - remember, zero value at next level is next power of two, not just
             one "unit", so cc=00, or overall 11000, is 256 now! Then are 512, 768
	     and maximum - 1024.
   * 1110d - at the last level only one bit it left, so there are just two
             values - 2048 and 4096.
   * 11110 - we also can define this as 8192, though no bits left
   * 11111 - similarly, maximum possible value will be 16384

   Extending one bit, we get Pyramint6 as follows:

   0aaaaa  - 0..31 * unit=1
   10bbbb  - 0..15 * unit=32    -> from 32    to max 512
   110ccc  - 0..7  * unit=1024  -> from 1024  to max 8192
   1110dd  - 0..3  * unit=16384 -> from 16384 to max 65536
   11110e  - 0..1  * unit=128 K -> from 128 K to max 256 K
   111110  - 512 K
   111111  - 1 M

   Extending one bit, we get Pyramint7 as follows:

   0aaaaaa  - 0..63 * unit=1
   10bbbbb  - 0..31 * unit=64    -> from 64      to max 2048
   110cccc  - 0..15 * unit=4096  -> from 4096    to max 65536
   1110ddd  - 0..7  * unit=128 K -> from 131072  to max 1048576
   11110ee  - 0..3  * unit=2 M   -> from 2097152 to max 8388608
   111110f  - 0..1  * unit=16 M  -> from 16 M    to max 32 M
   1111110  - 64 M
   1111111  - 128 M

   And finally, Pyramint8 will be:

   0aaaaaaa - 0..127 * unit=1
   10bbbbbb - 0..63  * unit=128   -> from 128    to max 8192
   110ccccc - 0..31  * unit=16384 -> from 16384  to max 512 K
   1110dddd - 0..15  * unit=1 M   -> from 1 M    to max 16 M
   11110eee - 0..7   * unit=32 M  -> from 32 M   to max 256 M
   111110ff - 0..3   * unit=512 M -> from 512 M  to max 2 G
   1111110g - 0..1   * unit=4 G   -> from 4 G    to max 8 G
   11111110 - 16 G
   11111111 - 32 G

pyramint4:                             1000 1001 1010 1011 1100 1101 1110 1111  
  0    1    2    3    4    5    6    7    8   16   24   32   64  128  256  512

TBD Pyramint9 for 2^45 perfectly matches max of 2^31 TSN * 16 Kb packet, has
it enough granularity on low values to avoid SWS ?
TBD is it really 2^45 ? recheck, seems only 2^44

TBD и что-то не сходится

2.6. Atoms & CBAR - Compact Binary Array/Record

  Атом есть числовое значение, используемое вместо некоей строки, чтобы не
  передавать эту строку, при этом не имеющее предопределенного константного
  значения, а согласуемое - что позволяет, например, более легкую расширяемость
  и/или выборочную поддержку фич. Например, атомами задаются имена алгоритмов
  (криптографических), имена поддерживаемых протоколов, наконец, сами адреса
  в сети, особенно при работе по нескольким адресам одновременно.

  Поскольку sockaddr_storage, согласно RFC 3493 ss_len
  как атом, то максимальная длина строки атома должна быть 128
TBD - 128 SHOULD? MUST?

  Атомы делятся на классы,

TODO или не делятся, перенести этот список в дерево sesctl

   В ряде мест применяется универсальная кодировка сложных структур данных,
   которая может быть единым парсером, чтобы не завязываться на конкретные
   форматы на низком уровне, когда не требуется большой экономии.

TBD а может таки класс, и тип тега, как опций в CoAP, типа вот приватные?

Huffman - 0 for Class=Auth, 5 bits max / 1 byte? но там же 4
0	 - 16	Reserved for future ext, len unkn, MUST throw decod err for now
10	 - 8	Special simple values, 1 byte only (no next bute)
11000	 - 256	ADDR_FAMILIES
11001	 - 256	ADDRS_SERVER
11010	 - 256	GENERIC_FEATURES
11011	 - 256	ADDRS_CLIENT	??? less bits?
11100	 - 256	LINK_VARS	??? less bits? name not link, ASSOC?
11101	 - 256	SESSION_VARS	??? less bits?
11110	 - 256
111110	 - 128	ENCRYPTION_ALGO
1111110  - 64	KEX_ALGORITHMS
11111110 - 32	MAUTH_ALGORITHMS
11111111 - 32	?? PUBKEY 

TODO

       Serial  Content | Meaning:
     Code | N  | Size  | Value is...
     =====+====+========+=====================================================
       0  | 0  |   0   | a NULL
       1  | 1  |   0   | empty (zero-length) string
       2  | 2  |   1   | string with length 1
       3  | 3  |   0   | the integer -1, or 0xFF..FF if unsigned is meant
       4  | 4  |   0   | the integer 0 and boolean false
       5  | 5  |   0   | the integer 1 and boolean true
       6  | 6  |   0   | the integer 2
       7  | 7  |   0   | Sublist / Tag: Special Parser Type Modifier
       8  | 8  |   1   | an 8-bit unsigned integer
       9  | 9  |   1   | an 8-bit twos-complement integer
     -----+----+-------+------------------------------------------------------
       a0 | 10 |   1   | a 8-bit atom, as 8-bit unsigned integer
       a1 | 11 |   2   | a 16-bit atom, as big endian 16-bit unsigned integer
       a2 | 12 |   2   | a string 2 bytes in length
       a3 | 13 |   3   | a string 3 bytes in length
       a4 | 14 |   4   | a string 4 bytes in length
       a5 | 15 |   5   | a string 5 bytes in length
       a6 | 16 |   6   | a string 6 bytes in length
       a7 | 17 |   7   | a string 7 bytes in length
       a8 | 18 |   2   | a big-endian 16-bit unsigned integer
       a9 | 19 |   4   | a big-endian 32-bit unsigned integer
       aa | 20 |   ?   | Reserved
       ab | 21 |   ?   | Reserved
       ac | 22 |   2   | a big-endian 16-bit twos-complement integer
       ad | 23 |   3   | a big-endian 24-bit twos-complement integer
       ae | 24 |   4   | a big-endian 32-bit twos-complement integer
       af | 25 |   2   | a big-endian IEEE 754 Half-Precision Float (16-bit)
     -----+----+-------+------------------------------------------------------
      b00 | 26 |   4   | a big-endian IEEE 754 Single-Precision Float (32-bit)
      b01 | 27 |   8   | a big-endian IEEE 754 Double-Precision Float (64-bit)
      b02 | 28 |   8   | a big-endian 64-bit unsigned integer
      b03 | 29 |   8   | a big-endian 64-bit twos-complement integer
      b04 | 30 |   0   | lrepeat: next code+4 is repeat count for next type code
      b05 | 31 |   5   | a big-endian 40-bit twos-complement integer
      b06 | 32 |   6   | a big-endian 48-bit twos-complement integer
      b07 | 33 |   7   | a big-endian 56-bit twos-complement integer
        N>=34  |  N-26 | a string with length N-26 (8 bytes or more)

   strings with lengths 8..255 will look from 0xb08 to 0xbff, so length is
   observable in low byte, and for strings with lengths 1..7 length is
   observable in low nibble

   Special Parser Type Modifier works depending on the type and length of next
   item:
   * if it is a string with length > 8, then it is mpint of this length
   * if it is a string with 0 < length <= 8, then it is Path OID of this length
   * if it is an empty string (length 0), then it is Path OID with length 9
   * other variants are currently reserved
TBD not so good
... may be shorten OID to max len 7 ? so vlezable in uint64_t

      Tag |   Data Item   | Semantics
     =====+===============+===========================================
       0  | byte string   | UTF-8 text string (no NUL terminator)
       1  | integer/float | Epoch-based date/time; Section 3.4.2 of RFC 8949
       24 | byte string   | Encoded CBOR data item (RFC 8949)
       26 | byte string   | Nested CBAR (full length, including header)

TBD no, to have atoms and for short strings, make 1 a shortcut for string till
end, and second nibble a tag
TBD so reassign tag 0 ? or make minus 1, so tags 0..14 ?

TBD probably 2 byte for tags enough, as it is in Content-Format

TBD may be 8-bit atom (address family) just in 0xFFyy?
-> or both, so 8-bit is for shorter strings

TBD sth in top 2 bits of OID: either content query or name query,
limit/offset/name1/name2/.../name8 are always in CBAR arguments

TBD a counter for sub-list instead of Nested CBAR? e.g for more than one Presentation Layer argument (e.g. zlib dict and CBOR dict)
- which variant, counter or start/stop code ?
- make one element equal to list of 1, for extensions without list bracketing / saving space ? not simple to parse
TBD seems that mpint not needed, just encapsulate SSH packet
TBD indefinite=concatenated strings in CBAR for Atom compression parts of, e.g. SSH packet?

TBD lrepeat (reuires 2 args - count and N elements)

TBD if CBAR as Tcl lists, then [cmdname args] may be like CBOR tags to parse,
e.g. LZF, and "cmdname" may be an atom instead of fixed tag number

<<String interning is supported by some modern object-oriented programming languages, including Java, Python, PHP (since 5.4), Lua[4] and .NET languages.[5] Lisp, Scheme, Julia, Ruby and Smalltalk are among the languages with a symbol type that are basically interned strings. The library of the Standard ML of New Jersey contains an atom type that does the same thing. Objective-C's selectors, which are mainly used as method names, are interned strings.

Objects other than strings can be interned. For example, in Java, when primitive values are boxed into a wrapper object, certain values (any boolean, any byte, any char from 0 to 127, and any short or int between −128 and 127) are interned, and any two boxing conversions of one of these values are guaranteed to result in the same object.[6]
History

Lisp introduced the notion of interned strings for its symbols. Historically, the data structure used as a string intern pool was called an oblist (when it was implemented as a linked list) or an obarray (when it was implemented as an array).

Modern Lisp dialects typically distinguish symbols from strings; interning a given string returns an existing symbol or creates a new one, whose name is that string. Symbols often have additional properties that strings do not (such as storage for associated values, or namespacing): the distinction is also useful to prevent accidentally comparing an interned string with a not-necessarily-interned string, which could lead to intermittent failures depending on usage patterns.>>

TODO 19.08.25 this topic was continued in files cbar.txt and nbor.txt

3. Установление соединения (ассоциации).

TODO RFC 5062 проблема restart - похищение адреса через tie tags
   An SCTP implementation should abort the association if it receives a
   SACK acknowledging a TSN that has not been sent.  This makes TSN
   guessing for the attacker quite hard because if the attacker
   acknowledges one TSN too fast, the association will be aborted.


  Установление ассоциации (соединения) клиента с сервером состоит из 4 шагов
  (в отличие от 3 в TCP и 2 в QUIC), как в SCTP:

  1) клиент посылает INIT
  2) сервер отвечает INIT ACK
  3) клиент посылает COOKIE ECHO
  4) сервер отвечает COOKIE_ACK

TBD клиент на MSS=24 может послать два пакета, распилив длинный cookie
пополам: один в COOKIE_ACK, другой в ECHO

  Такое разделение сделано с двоякой целью: во-первых, защита сервера от
  DDoS-атак co spoof-адресов (аналога SYN-флуда), во-вторых, клиент в
  начале еще не знает, на какой номер инстанса сервера его отправит
  балансировщик нагрузки.

  То есть, на стадиях 1-2 сервер не хранит полное состояние соединения, лишь
  чуть-чуть данных для проверки cookie и его воссоздания. Клиент должен
  ответить правильным cookie, которое он получил от сервера на шаге 2, так
  он подтверждает, что адрес реальный. Кроме того, на шаге 1 клиент шлёт
  запрос всегда на номер сервера 0, и получает в ответ номер сервера, на
  который должен отправить на шаге 3 и далее.

3.1. Общий формат пакетов INIT/INIT_ACK.

  Формат данных пакета INIT от клиента:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|0|                      Initiate Tag                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |mIS|mOS|mCh|IRW|      Optional Parameters
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....

  Формат данных пакета INIT_ACK от сервера:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |IRW|0|                      Initiate Tag                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |LimIS|LimCh|CookieLen|SrvInsNum|   Optional Parameters
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
     \                                                               \
     /                   State Cookie (8..71 bytes)                  /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TBD LimIS/LimCh - на Pfloat6 ?
TODO нет, 2-битные mIS, OS, Ch от клиента - экспоненты 2^(mIS+1), 2^(OS+1),
2^Ch; старшие биты полного 4-байтного Initial TSN, если есть - добавляют +4
в каждый слот (т.е. как бы старший бит)

  Оба варианта, и клиента и сервера, содержат Initiate Tag, который ДОЛЖЕН
  быть ненулевым. При этом, на шаге 1 клиент помещает 0 в свой Verification Tag
  в фиксированном заголовке, на шаге 3 и далее - помещает туда полученный от
  сервера Initiate Tag. То же самое делает сервер, то есть он ДОЛЖЕН в ответе
  на ECHO поместить в свой Verification Tag значение Initiate Tag от клиента.

Tag MUST be different from client and server

  То есть, клиент и сервер помещают значения, полученные друг от друга - то
  есть ожидаемые другой стороной, и далее эти значения НЕ МЕНЯЮТСЯ в течение
  всей жизни ассоциации.

  В SCTP чанки INIT / INIT ACK также включают в себя Initial TSN, но в muSCTP
  с целью экономии в пакетах INIT используются специальная обработка поля
  TSN Base из общего заголовка:

    * если длина TSN Base составляет все 4 байт, используется это значение
    * если длина TSN Base составляет 0, 1 или 2 байта, добавляется Packet Counter

  Как клиент, так и сервер могут выбрать использовать в качестве своего
  Initial TSN значение из Packet Counter, опционально сложенное со значением
  TSN Base в INIT-пакете. При этом как клиент, в особенности для Packet Counter,
  так и сервер должны приложить усилия для того, чтобы значения Initiate Tag и
  Initial TSN были по возможности случайными.

  Далее начинаются отличия. Пакет INIT от клиента включает в себя Ver - версию
  протокола (на данный момент 0). Предполагается, что версия самого формата
  будет меняться очень редко, и расширение будет вестись за счет новых номеров
  опций, параметров и зарезервированных полей.

  Сервер же может либо принять и работать на этой версии (предпоолагается, что
  он обновляется чаще клиента и может поддерживать несколько версий при
  необходимости), либо ответить ABORT при не той версии.

  И клиент, и сервер используют 2 бита IRW для значения Initial a_rwnd:

    * 00 - 0 байт, окно закрыто
    * 01 - 16 байт окна
    * 10 - 256 байт окна
    * 11 - 4096 байт окна (можно рассматривать как степень числа 16)

  Поскольку в начале соединения cwnd всегда имеет минимальное значение,
  полное значение окна сообщать не требуется - оно будет обновлено на
  настоящее первым же SACK.

  Далее сервер сообщает номер инстанса сервера, на который должны быть
  дальнейшие пакеты.

  Затем клиентский INIT опционально содержит параметры INIT - до конца опции.
  Сервер может содержать их же, но у него всегда есть обязательное значение
  Cookie, которое всегда идёт после параметров, если они есть, до конца пакета.
  Поэтому в CookieL указывается длина Cookie минус 8 байт, т.е. 32 значения
  дают возможность передать от 8 до 39 байт Cookie.

  Следует иметь в виду, что при минимальном MSS в 24 байта клиент сможет
  передать в опции ECHO только 22 байта, которая единственная займет весь пакет
  (для максимума нужен MSS хотя бы в 45 байт). Поэтому серверам РЕКОМЕНДУЕТСЯ
  помещать в Cookie минимально необходимый индекс для нахождения параметров
  ассоциации, а дальше начальную часть хэша (от секрета и данных, как в SCTP),
  сколько поместится. При этом серверам РЕКОМЕНДУЕТСЯ обрезать эту часть
  Cookie таким образом, чтобы суммарный размер пакета оказывался кратен 8,
  а лучше 16, байтам - с целью возможности упрощения реализации бэкендов (что
  не требуется, если известно, что данный бэкенд поддерживает любые значения
  длин для INIT), и допускать валидными обрезанные части.

TBD уменьшить ServInsNum
TBD до скольки? 6 бит? 5 бит? из компрессии CTag:28+Key:7+S:5=40=5 байт
-> для этого можно уменьшать Shared Key ID на малых (до 6), а ServInstNum
   делаем 6 бит - тогда с по 29 бит в ConnectionTag будут полные 64 бит
TBD прочекать бэкенды - может таки CookieLen до 6 бит поднять
 -> таки да

проблема Frags - в хранении состояния INIT на сервере, а хотели избежать DDoS
TBD для защиты от неё при выкачивании фрагментов ответа - какой-то токен? и MSS
TBD значит G даже для UDP, и Connection Tag в не-первых
TODO убрать MAC Len|NonceLen из туннелей, добавить MSS|MAC Trunc by
реальный максимальный размер INIT от клиента - 264 байта: 4 TSN Base + 5 header
+ 15 параметров по 16 байт + их 15 байт, остается возможным 16-й для pad

   Size Examples       MSS      Packet Size  MAC Len  Timestamp
    XS  802.15.4 UDP6  24-31    33-40        None     UQ8.3
     S  ICMP, ATM      32-40    48-56        4-8      UQ9.7
     M  6LoWPAN HComp  48-64    60-80        8-12     UQ11.10
     L  Censor base64  100-140  128-256      8-16     UQ14.10
    XL  Old e.g. SLIP  256-512  296-576      12-20    UQ22.10
   XXL  Normal IPv4/6  512+     576+         16-32    UQ32.14

TBD http://en.wikipedia.org/wiki/Q_(number_format) is for fractions, is it correct here?

3.2. Параметры INIT/INIT_ACK.

  Сами параметры INIT похожи на опции, но используют более простой формат без
  дельт и специальных значений:

       0   1   2   3   4   5   6   7
     +---------------+---------------+
     |               |               |
     |  Param Number |  Param Length |   1 byte
     |               |               |
     +---------------+---------------+
     \                               \
     /          Param Value          /   1..16 байт
     \                               \
     +-------------------------------+

  Только абсолютные номера от 0 до 15, и значение длины на 1 меньше, т.е. 0 в
  поле означает 1 байт - пустые параметры запрещены (пустые параметры могли
  бы означать булево значение самого факта поддержки чего-либо, поэтому вместо
  них можно использовать флаги в параметре 0). Соответственно, параметры (в
  отличие от опций) не требуют сортировки, и могут передаваться в любом
  порядке. Повторения номеров параметров запрещены, т.е. каждый из них ДОЛЖЕН
  передаваться не более одного раза.

  Параметры нужны для согласования поддерживаемых возможностей, актуальных на
  начало соединения и целиком на его длительность (а иногда даже дольше).
  В отличие от SCTP, ввиду нехватки места в параметрах нет адресов - для их
  согласования предусмотрены отдельные опции.

  По той же причине, форматы некоторых параметров отличаются в направлении от
  клиента или от сервера (т.е. в INIT или INIT_ACK). По умолчанию одинаковы,
  отличия будут указаны отдельно.

  На текущий момент определены следующие параметры:

   0  - INIT_PARAM_SUPPORTED_F
   1  - INIT_PARAM_SERVICE_NAME
   2  - INIT_PARAM_CLIENT_ID
   3  - INIT_PARAM_SESSION
   4  - INIT_PARAM_TIMESTAMP
   15 - INIT_PARAM_RANDOM_PAD

3.2.1. INIT_PARAM_SUPPORTED_F - 

TBD  На текущий момент определен один параметр, 0, в котором указываются, какие
  address family, т.е. типы SOCKADDR, поддерживает peer,

TBD TODO определить формат параметра 0 вместе с AF_*
или нет, нахуй, перенести это в стрим адресов, а здесь только флаги фич

3.2.9. INIT_PARAM_RANDOM_PAD

   Двоякое назначение: для padding INIT-пакета клиентом до кратного 8 или 16
   байт значения, и как дополнительный Nonce для применения в опции AUTH на
   еще не согласованных ключах, аналогично [RFC 4895]. Поскольку на известных
   ключах степень дополнительной защиты здесь мала - это защита только от
   слепого либо не видевшего INIT-пакет атакующего - к содержимому этого
   параметра не предъявляется серьезных криптографических требований.

   Так же, в виду применения для padding, это единственный параметр, которому
   разрешено встречаться более 1 раза или быть обрезанным - это дает
   возможность просто заполнить несколькими или даже одним байтом 0xFF.

3.2.2. INIT_PARAM_SERVICE_NAME

   This is a generalization of DCCP's "Service Code" concept ([RFC4340],
   Section 8.1.2).

TBD make their IANA standartization rules like in DCCP, too?
TBD same for Address Family etc. Atom Names?

   Байтовая строка, интерпретация на усмотрение имплементаций. Предназначена
   служить аналогом номера порта, или Virtual Host в HTTP, или именем
   IRC-сети, и т.п. Словом, понятным клиенту и серверу образом идентифицирует
   сервис - с чем именно устанавливается это соединение.

   Если параметра нет в INIT, это сервис "по умолчанию". Сервер МОЖЕТ
   проигнорировать значение параметра без всякой ошибки, если он не
   поддерживает различение сервисов. Также сервер МОЖЕТ сам передать клиенту
   в INIT_ACK такой же параметр - это будет означать "редирект", что данный
   сервис был "переименован".

старшие биты 10, т.к. невалидный utf8, для 18 7-битных символов,
или 111110xx yyyyyyyy для идентфикатора однобайтной кодировки, 14 символов
- 16.08.25 no, not codepages, Unicode compression from CBOR-TF7 or CBOR-GSM7
  could be used here, with possible further modification that we don't need
  C0/C1 controls, punctuation and similar, only lowercase is sufficient - so
  only BMP is enough (there is no point in emoji or ancient scripts from SMP,
  etc.), probably even before surrogates only
  - see added nbor.txt, names are NSCU, VNCSU, UTF-VN...

Reset Code 8, "Bad Service Code"

3.2.3. INIT_PARAM_CLIENT_ID

   Байтовая строка, не интерпретируется. Служит идентификатором клиента при
   наличии нескольких сессий. Имеет то же предназначение, что одноименное поле
   в MQTT. В принципе, имплементация сервера МОЖЕТ просто сконкатенировать
   этот параметр с байтами 2-16 парамтера INIT_PARAM_SESSION и использовать
   полученное значение точно так же и с той же семантикой, что и в MQTT -
   в данном случае можно сказать, что разделение на два параметра существует
   из-за слишком короткой длины параметра (в то время как даже старые версии
   MQTT позволяли ClientID размером 24 байта). Однако, другие имплементации
   могут использовать это разделение для удобства. Например, один и тот же
   клиент (тот же INIT_PARAM_CLIENT_ID) может открывать несколько сессий с
   разным значением QoS, или же обходить таким образом ту проблему, что
   в одной ассоциации muSCTP доступно лишь 16 пользовательских потоков (в
   отличие от потенциальных 65536 в SCTP или почти неограниченного числа
   подписок в MQTT), легко достижимое на практике значение.

TBD 3.2.2.3.7 Assigned Client Identifier ?

TODO not only client, but server ID also, thus node_id ? and lexicographical
order of this determines low bit in message ID

TBD what about global node_id instead of bit?
- seems no, time will be different in each session
- or possible? TIMESTAMP variant for proxy already present

3.2.5. INIT_PARAM_SESSION

TODO что мы определяем как сессию? отличия от MQTT ?

   В отличие от MQTT, где длительность хранения сессии может быть задана
   более миллиарда секунд, ресурсы constrained систем не безграничны, и даже
   в самом MQTT это значение часто ограничивается администратором брокера. 

   По аналогии с Chapter 2 Specification ZigBee (2015), Page 291, line 7683
   (3.4.11.3.1 Requested Timeout Field), в которой 15 значений сведены
   в таблицу от 0 для 10 seconds (0) до 14 для 16384 minutes (~ 11 days),
   в muSCTP применяется подобный подход для запросов длительности от клиента,
   и более отражающий человеческие настройки администратором - от сервера.

3.2.5.1. От клиента.

   Как упоминалось ранее, имплементация сервера МОЖЕТ просто конкатенировать
   два параметра, и в этом случае отсутствие INIT_PARAM_CLIENT_ID при наличии
   INIT_PARAM_SESSION просто означает пустую строку, когда используется лишь
   идентификатор сессии.
TBD да?

   Имеет формат 1 байта флагов и далее неинтерпретируемую байтовую строку до
   конца параметра, выступающую как идентификатор сессии:

      0                   1      
      0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-...
     |C|R|QoS|SExpiry| Session ID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-...

  где:

    * C, 1 bit - Clean Start as in MQTT
    * R, 1 bit - Reserved, must be 0
    * QoS, 2 bits - TBD
    * Session Expiry, 4 бита - requested session life time

TBD


   0 - Session ends when the Network Connection is closed. 
   14 - 675*2^15/86400=256 days
   15 - more than 256 days - maximum allowed by the server

TODO заменить бит R в обоих - has outstanding QOS_REL, for the peer to wait
for them and defer stream rewind needed to retransmit data

3.2.5.2. От сервера.

   Формат ответа сервером на INIT_PARAM_SESSION клиента - 2 байта, показывает,
   была ли сессия с таким идентификатором продолжена, либо начата новая,
   и время её разрешенной жизни после дисконнекта.

      0                   1      
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |P|A|Res|QoS|TU |  Expiry Time  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  где:

  P - Session Present
  A - Authentication required
  TU = Time Units:
  0 - минуты
  1 - часы
  2 - дни
  3 - недели

TODO это вектор DoS-атаки, перенести это в COOKIE_ACK
TBD чисто перенести мало, как быть с username/login? в SCRAM четыре шага

3.2.4. INIT_PARAM_TIMESTAMP

   От 2 до 5 байт, первый полный таймштамп.

      0
      0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |P|Res|Too|FracS| Time, Seconds, variable
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   P - Preliminary Stamp, "I will use your time if it differs too much"
   Res - Reserved
   P from server - "I have NTP synchronized clock"
   Too - how many seconds "too much" is, as 2^(Too+3), that is, 3 means 64 sec

TBD заменить Res/FracS на максимальную гранулярность таймера?

   Поскольку в INIT задержки непредсказуемы, точность более 1/8 секунды не
   требуется, которая и передается в FracS. Далее передается время в секундах,
   целое, Unix Time, MSB. Длина зависит от того, сколько передает протокол
   туннеля: если тот передает старшие биты, здесь достаточно младших для
   получения уточненного значения, если же он передает только младшие, здесь
   должно быть полное 32-битное значение.

   Поскольку время на клиенте может быть совершенно не синхронизированным
   (быть, например, дефолтным значением типа 2000 года при включении), для
   уменьшения используемой дельты в обычных пакетах - он может просто взять
   значение с сервера (предполагается, что сервер имеет более-менее правильное
   время на себе), и в дальнейшем применять этот bias внутри себя.

   Следует отметить, что формат позволяет серверу тоже передавать P-флаг
   и таким образом синхронизироваться с клиентом, однако это не является
   расчетной конфигурацией и должно применяться только вручную настройками на
   both клиенте и сервере.

   Назначение этого параметра, и главным образом P и Too, связано с тем, что
   в туннелях с предельно низким MTU в одном из направлений может передаваться
   даже не полный таймштамп, а дельта времени между таймштампами клиента
   и сервера, позволяющая его вычислить. В этой дельте будет лишь небольшое
   число бит для целой части (секунд), таким образом, ограничивая максимально
   возможное расхождение времени между клиентом и сервером - причем следует
   учесть, что их часы могут идти с разной частотой (drift/skew в терминах
   NTP). Это может приводить к увеличению разницы со временем - до десятка
   секунд в сутки в очень плохих случаях, что скажется на долгоживущих
   соединениях. Поэтому здесь ДОЛЖЕН быть передан параметр, дающий минимум из
   всех поддерживаемых дельт туннелей, умноженный на 4 (т.е. для дельты 5 бит
   значение 3 дает Too=0), и РЕКОМЕНДУЕТСЯ иметь это соотношение как
   "в 2 раза шире".

   Rationale: ограничение сверху в 64 секунды (6 бит) проистекает как из
   бессмысленности очень широких дельт (в них есть и дробная часть), когда
   проще может оказаться передавать полные значения минимально разрешенной
   ширины, так и из сравнения по 2 MSL минимально разрешенной ширины 8 бит:
   дельта знаковая, и -63..+64 секунды дают половину интервала, больше
   которого уже может возникнуть двусмысленность.

-- variant unfragmented

  Format of INIT from client:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|0|                      Initiate Tag                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |mIS|OS |mCh|IRW|SExpiry|SLength| Flags and Lengths, VarUInt32  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+
     |   Time since Epoch, Seconds, 4 bytes, present if T flag set   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /           Service Name or Session ID (1..16 bytes)            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /   Options in usual format, for CBAR parameters & user data    /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /     Padding (ignored), if underlying protocol requires so     /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TBD 3 new bits in Initiate Tag? or not, if it is it's length?

  Format of INIT_ACK from server:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |IRW|0|                      Initiate Tag                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |mIS|OS |mCh|ServInstNum|CookieL| Flags and Lengths, VarUInt32  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+
     |    Time since Epoch, Seconds, 0/1/2/4 bytes, by TEL field     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                   State Cookie (8..23 bytes)                  /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /   Options in usual format, for CBAR parameters & user data    /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /     Padding (ignored), if underlying protocol requires so     /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The flags from client:
  (note bits numbering from right)

        2                |2 1            |    1      |
        9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Reserved              |MaxHI|C|Too|S|TEL|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    * C, 1 bit - Clean Start as in MQTT
    * Too - how many seconds "too much" is, as 2^(Too+3), that is, 3 means 64 sec
    * MaxHI - maximum length of Host IDs supported by client, in TBD-bit
      words

  The flags from server:
  (note bits numbering from right)

        2                |2 1            |    1      |
        9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Reserved                    |A|QoS|S|TEL|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  A - Authentication required

  Common flags:

   TEL - Time since Epoch Length, how many bytes of Full Timestamp are present:
     00 - none (timestamp field absent)
     01 - 1 high byte
     10 - 2 high bytes
     11 - full 4 bytes TBD or 3 ? do we require tunnels to provide low 8 bits in INIT too?
   S - Synchronize:
     * from client: "I will use your time if it differs too much"
     * from server: "I have NTP synchronized clock"

TBD data in INIT pkt / cookie like RFC 7413 TCP Fast Open - but based on time?
- 02.04.26 yeah, it solves duplicate SYNs but see 5.1.1, 5.2, 6.3.3, 7.2
TBD no CBAR length, but just usual option format, and CBAR inside INIT option?
-> no, inside TSN chunk so retransmit is natural
  TBD hash of it in State Cookie?
  TBD flag from server about "INIT opts/chunks are not ignored (no need to retransmit)"?

TBD proxy - e.g. for inspecting by firewalls, service request?
  TBD how to ATOM_CONFIG and timestamps via inspecting proxy as atom set could differ?
  -> separate DUP flag from timestamp and pass them in CBAR; atoms and all
     over config stream translated by proxy, except proxy.* subtree

TBD tun problem - which of INIT? in gray mode each retransmit should have fresh
timestamp for hiding, then, in case of loss, how to distinguish replies to them?
- in ICMP this is solved automatically by echoing all, think about similar
  echoing in other tunnels

TBD similar problem exists with retransmits in ESTABLISHED state...

-- /variant unfragmented

   SCTP used a trick where server does not keep any state at all by packing
   entire TCB info into cookie, resulting in more than a hundred bytes, which
   is, of course, unacceptable for constrained environments. However, is such
   need will arise in the future, some option for extending cookie may be used.

  Format of ABORT packet:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|0|1|                          0                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |SRT|       Echo of Connection Verification Tag of Sender       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /             Stateless Reset Token, 0..SRT words               /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /         CBOR indefinite-length array with Error Causes        /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /     Padding started with 0xFF, ignored, optional - if         /
     \          underlying protocol requires so                      \
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The indefinite-length array terminating 0xFF byte is implicit: if no
   Padding present, then receiver virtually appends this byte for CBOR parser,
   if required by implementation; or with Padding the 0xFF byte will be 
   explicitly present, then everything after it MUST be ignored by parser.

   The difference between ABORT chunk and ABORT packet is that for ABORT
   chunk, an association in ESTABLISHED state exists, so that sender of ABORT
   chunk can properly fill it's own Connection Verification Tag and
   encrypt/authenticate the packet, while for ABORT packet, association (and
   state) does not exist, either because it's not yet created (case for error
   in INIT packet) or other reason (e.g. sender mistaken address).


3.3. Процедуры.

  В конечном итоге, после получения Cookie в INIT_ACK, клиент отправляет пакет
  на указанный номер сервера с опцией ECHO, телом которой является содержимое
  Cookie - это шаг 3. Следует отметить, что на этом шаге уже возможна отправка
  клиентом и пользовтельских данных, если окно сервера открыто - сколько их
  влезет в пакет после Cookie.

  Сервер на шаге 4 отвечает либо COOKIE_ACK, если полученное Cookie его
  удовлетворило, либо ошибкой - например, значение Cookie могло устареть, и
  клиенту придется получить его заново.

  После этого шага ассоциация считается полностью установленной (сервер тоже
  может передавать данные на шаге 4). В установленном состоянии опция ECHO
  используется уже не для Cookie, а для ответа на опцию HEARTBEAT.

TODO диаграмма состояний

4. Опции в состоянии ESTABLISHED.

  Поскольку минимальный поддерживаемый размер пакета очень мал (32 байта), и
  недостаточен для вмещения ряда структур, то для их передачи применяется
  собственная же система, используемая для передачи пользовательских данных:
  фрагментация блоков, назначение фрагментам TSN и подтверждение их в SACK.
  Такого рода опции используют как бы отдельный поток, в дополнение к 16-ти
  пользовательским, с сокращенным размером, окном и форматом - без нумерации
  блоков внутри потока.

  Все опции, использующие единый алгоритм фрагментации и подтверждения TSN,
  имеют единый формат первого байта:

      0                   1
      0 1 2 3 4 5 6 7 8 9 0
     +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+...-+-+-+-+-+-+-+-+-+-+-+-+...
     |TSN Delta|B|E|S| header... | Msg Length/FSN | Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+...-+-+-+-+-+-+-+-+-+-+-+-+...

  где:

    * TSN Delta, 5 бит - прибавляется к TSN Base пакета для получения TSN
      данного чанка
    * S, 1 бит - specific, интерпретируется специфически для каждой опции
    * B, 1 бит - (B)eginning fragment bit, первый фрагмент сообщения
    * E, 1 бит - (E)ending fragment bit, последний фрагмент сообщения

  Биты B и E описывают фрагментацию сообщения и наличие и интерпретацию поля
  длины блока / смещения фрагмента, размер и расположение которого зависит от
  конкретного типа опции, следующими возможными комбинациями:

       B E  Msg Len/FSN                 Описание
     =======================================================================
     | 1 0 | Msg Length | First fragment of transmitted message            |
     +-----+------------+--------------------------------------------------+
     | 0 0 | FragSeqNum | Intermediate fragment of transmitted message     |
     +-----+------------+--------------------------------------------------+
     | 0 1 | FragSeqNum | Last fragment of transmitted message             |
     +-----+------------+--------------------------------------------------+
     | 1 1 | <no field> | Unfragmented: entire message is in this chunk    |
     =======================================================================

  Фрагментация осуществляется способом, подобным IP-пакетам: указывается
  байтовое смещение в каждом фрагменте, если он не первый. Если же он первый,
  то вместо смещения передается полная длина ожидаемого блока для получателя,
  чтобы тот знал, сколько следует выделить ресурсов, или же (в случае обычных
  пользовательских данных) мог отвергнуть слишком длинный блок. Когда блок
  достаточно мал, чтобы целиком влезть в одну опцию и пакет, т.е. оба бита
  B и E равны 1, то поле длины/смещения не требуется и для экономии не шлётся.

TBD а ну как для потоков с 1 in-flight сделать S младшим битом SeqNum
TODO переделать все потоки на длину только при BE=10, без Offset в остальных
TBD а получится? в SCTP добавляли идентификаторы для чередования, сможем без них?

-- variant 2

похоже, что нет - нужно поле FSN: допустим, у нас есть пропуски в TSN, тогда
мы не можем собрать блок, пока не получили все блоки, что начисто убивает идею
unordered-блоков и элиминации Head-of-Line Blocking; при коротких FSN мы тоже
не можем это сделать при пропусках больше ширины FSN

-- /variant 2

TODO длина указывается затем, чтобы в конечном (E) чанке можно было передать
значение MAC value - последними байтами, после данных; для BE=11 это
невозможно, применяется чанк AUTH на весь пакет

4.1. SACK: Selective Acknowledgement. 

  Основной механизм подтверждения доставки всех чанков, имеющих TSN. Размер
  от 4 байт до четного максимума.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Cumulative TSN Ack                       |
     4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Shift|  a_rwnd's mantissa      |SACK #0|SACK #1|GAP#2 S|GAP#2 E|
     8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | SACK #3 |Len#3| SACK #4 |Len#4|  SACK #5  |L#5|  SACK #6  |L#6|
    12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   SACK #7   |L|    SACK #8    |GapAkBlk#9 Strt|GapAckBlk#9 End|
    16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Gap Ack Block #10 Start     |  Gap Ack Block #10 End        |
    20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Gap Ack Block #N Start      |  Gap Ack Block #N End         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Поле Cumulative TSN Ack, как и в SCTP, дает номер последнего успешно
  полученного TSN без пробелов в последовательности. В muSCTP оно всегда
  полные 32 бита в SACK, потому что как раз здесь мы имеем дело с потерями
  пакетов и не имеем надежной точки, относительно которой компрессировать - а
  Packet Counter могут быть разные по разным путям передачи. Как и в SCTP, при
  еще пока отсутствии блоков, оно равно Initial TSN минус 1.

  Далее идут 2 байта поля Advertised Receiver Window Credit (a_rwnd), дающего
  обновленный размер приемного буфера получателя (то есть отправителя этого
  SACK). Поле разбито на 2 части: 3 бита сдвига и 13 бит мантиссы. Сдвиг
  описывает, на сколько бит влево нужно сдвинуть мантиссу, чтобы получить
  значение окна, для максимум 7 мы из 13 бит получаем 20, то есть максимальный
  размер окна составляет чуть менее 1 Мегабайта. Точные значения окна, как
  можно заметить, получаются для значений менее 8191 байт, в остальных они
  немного округляются вниз - что не представляет проблемы, пока окно не забито,
  в противном случае получатель обновит его более точными значениями.

TODO a_rwnd может быть обрезано вместе со всей опцией, тогда в случае 1 байта
и нуля байт применяются форматы/значения опции MORE_DATA
TBD а если на нормальных MTU окно больше мегабайта? может до 3 байт уметь?
тогда T+Shift - до 27 битов окно в итоге, 128 Мб
нет, на 2 байтах T+Shift4 - до 26 бит, а на 3-х к Shift add bias so 31 bit max
TBD еще же окно внутренних потоков - или его в отдельном чанке?
      0               
      0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+
     |Exp|a_rwnd+|IW+| - Exponent & IW+ are WU2 (=16^ as in INIT)
     +-+-+-+-+-+-+-+-+


-- variant 2: нет, этот способ пойдет в MORE_DATA и в вектор, а здесь надо
точные для пакетов длиной <11 бит, как минимум
TODO расписать 3 бита из TSN

TODO это и в SACK-блоках можно:

      0                   0                   0               
      0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7    ,- TBD
     +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+ <-' чото тут
     |0|   Bitmap    |   |1 0| Huff 1's  |   |1 1 0|O 0 in 32| не оч,передумать
     +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+  мб 0 и N 1's

      0                       Pyramint6 
      0 1 2 3 4 5 6 7    TBD какие add к ним? а то перекрываются
     +-+-+-+-+-+-+-+-+
     |1 1 1|Huff 0's |
     +-+-+-+-+-+-+-+-+

-- /variant 2

TBD silly-window syndrome?
-> this is why window bits can't be too less than max MTU


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Cumulative TSN Ack                       |
     4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |UWL| int_rwnd  | a_rwnd, 0..3 bytes      |SACK ranges ...
     8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

int_rwnd always Pyramint6

       |0 0| int_rwnd  | SACK range #1 |
     8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

       |1 0| int_rwnd  |arwnd Pyramint8| SACK range #1 | SACK range #2 |
     8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |0 1| int_rwnd  |Shift|   a_rwnd's mantissa     | SACK range #1 |
     8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- so 1 Mbyte max


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1| int_rwnd  | Shift |a_rwnd's mantissa with implicit right 1|
     8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

real shift if Shift+26 so max is 2^42 (2^32 TSN + 2^11 TSN chunk but really coz it's Answer haha)

TBD wait, all zero should equal to 1 Mb


TODO

4.2. BYTESTREAM_CHANNEL: Bytestream Channel Operations

TBD или нет, лучше на channels из SSH - отдельное пространство номеров

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|L|B|E|Strm ID| Stream Sequence Number|OpCode |Len/Err|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
     |Len ext.(opt.) |  Initial Window or Window Adjustment (opt.)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
     .            Payload Protocol Identifier (optional)             .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               \
     \   CBAR data (optional) of Request Params or Error Description /
     /                                                               \
     +---------------------------------------------------------------+

  Здесь бит A означает, при нуле, запрос, или 1, если это ответ - в случае
  успеха. В противном случае, например при отказе, вместо этого шлётся
  опция ERROR.

  Stream ID задает номер потока, в котором будет начат байтовый поток (т.е.
  возможны одновременные запросы до получения подтверждения по нескольким
  потокам).

  Stream Sequence Number означает номер блока, который будет первым из тех,
  что принадлежат уже байтовому потоку, а не обычным блокам. Он ДОЛЖЕН быть
  строго больше (по серийной арифметике), чем последний подтвержденный блок
  в этом потоке - это дает возможность закончить отправку блоков, уже
  находящихся в буфере передачи. Однако, рекомендуется посылать запрос как
  можно позже, поскольку получатель вправе лимитировать количество обычных
  блоков, ожидаемых до открытия потока, и ответить соответствующей ошибкой.

TODO для Window Adj же не нужен SSN
TBD переместить его в новую опцию stream control

  Если всё нормально, получатель отвечает с битом A, тем же номером, и, в
  свою очередь, своим номером SSN встречного направления, который будет
  первым блоком байтового потока.

  Если длина опции равна 7, то присутствует поле Payload Protocol Identifier.
  Оно никак не интерпретируется muSCTP (в частности, не конвертируется порядок
  байт), и служит только как подсказка получателю.

TODO какой таймер на ответ? T4-RTO ?

Unfortunately, there is no symmetric way for
an endpoint to request that its peer should cease sending data to it
while still keeping the channel open for the endpoint to send data to
the peer.

This is desirable, since it saves the transmission of data that would
otherwise need to be discarded and it allows an endpoint to signal local
processes of the condition, e.g. by closing the corresponding file
descriptor.

OpenSSH implements a channel extension message to perform this
signalling: "eow@openssh.com" (End Of Write). This message is sent by
an endpoint when the local output of a session channel is closed or
experiences a write error. The message is formatted as follows:

	byte		SSH_MSG_CHANNEL_REQUEST
	uint32		recipient channel
	string		"eow@openssh.com"
	boolean		FALSE

On receiving this message, the peer SHOULD cease sending data of
the channel and MAY signal the process from which the channel data
originates (e.g. by closing its read file descriptor).

As with the symmetric SSH_MSG_CHANNEL_EOF message, the channel does
remain open after a "eow@openssh.com" has been sent and more data may
still be sent in the other direction. This message does not consume
window space and may be sent even if no window space is available.

-- variant 2:

   CHANNEL_OPEN                    0
   CHANNEL_OPEN_CONFIRMATION       1
   CHANNEL_OPEN_FAILURE            2
   CHANNEL_DATA                    3
   CHANNEL_WINDOW_ADJUST           4 # to INTERCHUNK_STREAM_CONTROL ?
   CHANNEL_EOW                     5 TBD
   CHANNEL_EOF                     6
   CHANNEL_CLOSE                   7

   CHANNEL_OPEN/CHANNEL_OPEN_CONFIRMATION:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|L|B|E| Cmd |Stream ID|    Stream Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
     |LenHi|A|PPI|IWH|  Initial Window or Window Adjustment (opt.)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
     |Auth HMAC's AlgParKeyLen (opt) |Length, if E=0 |    Atom or    \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
     .     ShortString or Payload Protocol Identifier (optional)     \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               \
     \      Request Params Data or Error Description (optional)      /
     /                                                               \
     +---------------------------------------------------------------+

   CHANNEL_DATA:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|L|B|E|   Stream ID   |    Stream Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
     |   | Cmd |LenHi|Length, if E=0 |                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
     /                                                               \
     \                  User Data, at least 1 byte                   /
     /                                                               \
     +---------------------------------------------------------------+

openssh не использует channel-specific аргументы CHANNEL_OPEN_CONFIRMATION 

если убираем окно и HMAC в STREAM_CONTROL (там могут быть заданы дефолты для
новых), то нужда в битах:
CHANNEL_OPEN              - PPI, Compress, длина
CHANNEL_OPEN_CONFIRMATION - Compress (мб резерв?) 
CHANNEL_OPEN_FAILURE      - код ошибки, строка, укороченная длина
CHANNEL_DATA              - длина - сколько? 11 бит чтоб TSN не чаще?
CHANNEL_EOW               - нет
CHANNEL_EOF               - нет
CHANNEL_CLOSE             - нет

для 28 бит ID+SSN остается 4 бита:

00PI   CHANNEL_OPEN              - длина до 64 Кб
01LM   CHANNEL_DATA              - длина L+LM+LenByte
1000   CHANNEL_OPEN_CONFIRMATION - нет
1001   CHANNEL_EOW               - нет
1010   CHANNEL_EOF               - нет
1011   CHANNEL_CLOSE             - нет
110    CHANNEL_OPEN_FAILURE 
111 Reserved

TBD open_failure и close в один reset? в QUIC приложение может код ошибки
в данных при резете посреди стрима

TBD а зачем PPID ? и компрессию тоже в STREAM_CONTROL убрать?
пока что похоже, компрессия только здесь и возможна, в блоках длину распак где
TBD на размер данных можно в конфиге лимит, если 64 Кб много?

unidirectional не нужен - достигается EOW и EOF
TBD а как быть с stderr? в SSH про EXTENDED_DATA_STDERR:
   Data sent with these messages consumes the same window as ordinary
   data.
вообще, если stderr нужен, можно по блочному стриму пустить, а channel не
усложнять - ведь еще в API кучу всего поменять придется, и peeloff проблема

TBD сколько бит на SSN ? похоже, при окне 32 и пакете 11 выходит 22 max

-- /variant 2:

-- variant 3:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|1|E|L| Cmd |         Stream Sequence Number          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Stream ID    |Length, if E=0 |                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
     /                                                               \
     \                  User Data, at least 1 byte                   /
     /                                                               \
     +---------------------------------------------------------------+


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|0|E|  FSN  |         Stream Sequence Number          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Stream ID    |                                               \
     +-+-+-+-+-+-+-+-+                                               /
     /                                                               \
     \                  User Data, at least 1 byte                   /
     /                                                               \
     +---------------------------------------------------------------+


-- variant 4:

CHANNEL_DATA:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|1|E|1|LenHi|         Stream Sequence Number          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Stream ID    |LenLow, if E=0 |                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
     /                                                               \
     \                  User Data, at least 1 byte                   /
     /                                                               \
     +---------------------------------------------------------------+

all other commands

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|1|E|0| Cmd |         Stream Sequence Number          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Stream ID    |   Length, VarInt15, if E=0    |               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
     /                                                               \
     \              Control Data, CBAR, at least 1 byte              /
     /                                                               \
     +---------------------------------------------------------------+

TBD LSL - 2-bit Logical Stream ID Length TBD or 1 bit?
- ANT: надо только один уровень стримов для окна/в API

TBD

4.3. CRYPT: Crypto Config Stream Data. 

  Формат опции потока с криптографическими данными мало отличается от общего
  для всех TSN chunks:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |TSN Layer|B|E|L| Length, opt.  |Opcode/FSN/SSN | Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |TSN Layer|1|0|L| Length, L+1 b |SSN|  Opcode   | Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |TSN Layer|0|E|  Offset TSN |SSN| Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

  Bit L is for length of Length field, if it is present: 1 byte if L is 0,
  or 2 bytes otherwise. Length itself is after SSN/Opcode byte (that is, 0
  if only SSN/Opcode present), thus maximum cryptographic message size is 65535
  bytes, which is enough, for example, for Noise Protocol Framework.

  As there is just 2 bits for Sequence Number, only one message allowed to
  be in flight, that is, crypto stream is operated in stop-and-wait mode.

TBD or more? SSH2_MSG_NEWKEYS in both directions and it's timestamp as Key ID
for subsequent assignment to per-address Shared Key ID in sesctl? or just
increment common key id in each negotiation? next_slot?

  Messages on CRYPTO stream are described in Section 5.2.

4.4. DATA: User Payload Data.

  Формат в опции чанка с пользовательскими данными:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|U|B|E|Strm ID| Stream Sequence Number|BLL|Blk Len/Ofs|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ... 0, 1, 2 или 3 байта продолжения Block length / Offset       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..............+
     /                                                               \
     \            пользовательские данные, минимум 1 байт            /
     /                                                               \
     +---------------------------------------------------------------+

  Начало - стандартное для всех TSN chunks, с TSN Layer и битами B/E. Для
  пользовательских данных поле Block Length/Offset может иметь длину от 6 бит
  до 30 бит, т.е. от 1 до 4 байт - количество байт продолжения задается
  битами BLL, только сам байт (6 бит) в случае нуля, еще 1 байт (6+8=14 бит)
  в случае 1, и т.д. Таким образом, максимальный размер блока - почти 1 Гб.

Rationale потому что в SQLite максимум 2 Гб на строку таблицы в сумме

  Stream ID задает номер потока, от 0 до 15. Поскольку их число настолько
  ограничено, в отличие от SCTP, нет их согласования, т.е. реализации ДОЛЖНЫ
  всегда поддерживать все 16 потоков, не меньше.

  Бит U - Unordered, как и в SCTP, что может использоваться для "срочных"
  сообщений, пока доставляется большой "обычный" блок.

  Stream Sequence Number, 12 бит: номер текущего передаваемого блока в этом
  потоке. Пространство этих номеров раздельное для ordered и для unordered
  блоков. В случае ordered-блоков, этот номер доступен пользовательскому коду
  на отправляющем и принимающем концах, для unordered-блоков он применяется
  сугубо для отличения блоков друг от друга.

  Нумерация блоков подчиняется стандартной арифметике серийных номеров, т.е.
  wrap в 0 после достижения максимального значения, а также это значит, что
  одновременно в сети ДОЛЖНЫ находиться не более половины пространства номеров,
  что ограничивает максимальную скорость передачи данных по одному потоку в
  случае мелких сообщений. Поэтому ширина этого поля не сильно уменьшена, 12
  бит относительно 16 в SCTP, где свежие расширения поднимают его до 32.

TBD: может уменьшить дельту и SSN? но по ним ротация seq number arithmetics...

TBD если TTL в PFloat7, то от 675/0.125=90 минут до ~40 мс

TBD в чанке STREAM_CONTROL назначать и AlgParKey для unordered - экономим байт

TBD вариант PPID как атом, причем если он 4 байта, receiver MUST present as 4
bytes instead of atom - this makes porting SCTP apps easier (just mechanically
change function calls instead of explicit atoms logic)

TBD так как в unordered нет prev PPID - объединить его Хаффманом с AuthLen? или
даже не Хаффман, а space 0..31 поделить на 3, причем длины >= 4, см. CCM RFC3610

TODO auth надо считать не только по данным, а и заголовок, а то от 1 байта плохо

TBD initial window 26 бит, причем старшие только 3 значения либо "без окна",
т.к. байтов на половину FSN будет 1535*32768=48 Мб окна

TBD в U компрессия ведь не нужна на BE=11, else одного бита мало, и для MAC
тоже надо дать настроечный байт

   BE=10                  BE=00              BE=01              H - Header
   +----------------+     +----------------+ +----------------+ F - FSN
   |HHHHBPPAabcdLLUU| ... |HHHHFFUUUUUUUUUU| |HHHHFFUUUUUUefgh| L - Length
   +----------------+     +----------------+ +----------------+ U - User Data
           \___/                                          \__/  P - PPID/Atom
             \________ MAC value is "abcdefgh" ____________/    A - MAC Algo 

* для Ordered:
  0 - prev
  1 - full PPID
  2 - Atom + 1 byte Content-Format
  3 - Atom + 2 byte Content-Format
* для Unordered, s/Com/Key/ и:

  bytes left        0    1    2    3    4    5    6
  -------------------------------------------------
  nothing           0    1    2    3    4    5    6
  Atom, no C-F      7    8    9    10   11   12   13
  Atom, C-F 1 byte  14   15   16   17   18   19
  Atom, C-F 2 byte  20   21   22   23   24   25
  PPID              26   27   28   29   30   31

!! при ordered же чанк AUTH, значит на BE=11 реально есть только 14 байт,
включая заголовок опции, т.е. 12 байт максимум, и состыковать это с unordered
auth на BE=10

TBD после FORWARD_TSN должен происходить сброс prev

-- variant 8: 

без бита дефолта, и получаем 512 номеров стримов
под такой размер FSN - для CHANNEL при 3 битах Cmd выходит 21 бит SSN
и 8 бит номер стрима, 256

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|B|E|U|    Stream Sequence Number     |Stream ID, 9 bi|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |t|  FSN, 6, 13 or 21 bits Huf: 0, 10, 11       | User Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

F - bool for Presentation Layer

ordered:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|1|E|0|    Stream Sequence Number     |Stream ID, 9 bi|
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |t|X|QoS/D|F|PPL| | Opt. X byte |T| TTL (Pfloat7) / Dup 1/2 byte|
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     . Content-Format or Payload Protocol Identifier, opt, 0/1/2/4 b .
  12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |BLL|BlkLen'sBeg| ... BLL bytes (0-3) continuing Block Length   |
  16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..............+
     | User Data...
     +-+-+-+...

unordered unfragged:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|1|1|1|    Stream Sequence Number     |Stream ID, 9 bi|
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |t|X|H|T|F|PPL|R| Opt. X byte |T| TTL (Pfloat7) | Content-Format .
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | or Payload Protocol Identifier, opt, 0/1/2/4 b|  User Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

unordered first:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|1|0|1|    Stream Sequence Number     |Stream ID, 9 bi|
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |t|X|H|T|F|PPL|L|  Opt. X byte  |T|TTL (Pfloat7)| Content-Format.
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     . or Payload Protocol Identifier, opt, 0/1/2/4 b|AuthIndxLen|Len|
  12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .     Begin of HMAC, Len+1 (1..4) bytes, if AuthIndxLen > 0     .
  16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Data Length, L+1 (1..2) bytes  | User Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

-- variant 8.1: так же, но 8 бит / 256 стримов, для U переносим L в байт Auth
и 1 бит длины начала HMAC задает 4 или 6 байт; отдаем освободившийся бит под
Presentation Layer или в резерв для X ?
-> наверное лучше 4, под method/reply/error/event

-- /variant 8

-- variant 9: как 8.1, но снижаем SSN до 12 бит, а время до 10 бит - это
миллисекунды, 

Rationale:
1) это даст возможность уложить полный идентификатор сообщения
   в 64 бита (1 бит клиент/сервер и 1 резерв)
2) для экономии важен размер средних сообщений, т.е. FSN, в B=1 недефолтные
   всегда можно выделить, это без проблем

Для ordered в остаток кладем PPL и Ext, для unordered TBD мож сразу H|T без
расширений сделать?
-> пожалуй да, причем H вынести как необязательно приоритет, но можно тоже
   для PresLayer (Compress/Dict), а бит длины MAC сделать Fill: либо 4 байта,
   либо заполняет сколько можно, пока не останется длина + 1 байт User Data,
   или не закончится HMAC

TODO QoS/D|A|PrLayer| - и для A имеем полный идентификатор ответа в ДАННЫХ,
точнее, интерпретация Append/Answer - на усмотрение PresLayer
- или Augment: для partial смещение, для ссылки на блок - возможность "prev"

TODO требует переделки QoS и ABANDON_BLOCKS

-- /variant 9

TODO смещение в DUP для докачки, использовать для него тоже бит A, также
привязать его в QOS_PARTIAL и промежуточный HMAC - чтобы в т.ч. при ошибке
чексуммы нижнего уровня не надо было перекачивать весь 1 Гб

-- variant SQL: H в AuthIndxLen и длина, в остальном одинаково для U/O,
сделать short format как выше, и long в CBAR, еще zero? TBD id время+U?
-> VarInt15, если <127 то биты short, иначе CBAR 32768-128=32640
   в шорт QoS=11 и дальше биты - номер 512-сектора, это блок-часть
   ...тогда как QoS в лонг формате?

      0                   0                   1
      0 1 2 3 4 5 6 7     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|QoS|PPL|T|Add|   |1| CBAR Length - 128, 32640 max|
     +-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Add: 00 = NULL, 01 = 1 byte << 9, 10 = 2 bytes << 1, 11 = 2 bytes << 1 + 1
-> no, 2 bits ASh - shift 0/4/8/12 bits, and Add as VarUInt32
  TBD in CBAR also ASh os low 2 bits?
  TBD for proxy will need DUP flag separate from timestamp, so S - Shift present in low 5 bits?

version (schema?) field in CBAR, fields after which are extensions interpreted
according to it

PPID as first/only element in Presentation Layer sublist
DUP is time_t only - always has lower uint32 as Add in CBAR?

thisLength, type?
userLength,
offset,             ; also under DUP flag? 20 bits enough
cbarLength,
[
	QoS: 0..2,
	DUP: bool,              ; TBD no need if just tv_sec presence
	tv_sec: uint / null,    ; needed for inspecting proxy - move to TIMESTAMP opt?
	tv_usec: uint / null,	; how to Add/Shift?
	TTL: uint / null,
	PresLayer: uint .size 2 / bstr / array,
]

0    - Add is 1 byte, shift is to get 10 bit - milliseconds
1,2  - Add is 1/2 byte, shift is to get 20 bit - microseconds
..

no, let's think TSN layer provides us with full 20 bits, so Add to full msgid
have to be at most 10 bit.. may be shifted?
or 2-bit Add as method number, default method 0 is low bits of stream num

TBD 09.11.24 (see also this day) if we are going to options inside TSN chunk,
then DUP/tv_sec/tv_usec and possibly Add may be provided by TSN layer in
options?

userLength/offset are possible even in single block, e.g. continue small tail
from previous sess

TBD seems that offset is inevitable, but if reduce Stream ID to 10 bits, then
with custom Offset format SID+Offset will expand 4 bytes max; same field
would be used for TSN Offset (thus more than 32768 TSNs); also it fits nicely
for Unordered middle chunks, as 2 bits for flags would unused otherwise (but
TSN Offset still limited to 32768); also ideal for Message ID with stream
number; the only sufferer is legacy Channel - reducing SSN to 19 bits

TBD for Unordered may have Offset in middles also 20 bits - use 2 bits for SSN interleaving offset
- no, this must in B=1, and there is space only if cut more bits from
  length...

TBD need to fix Parent in Window in STREAM_CONTROL for this? or just Arg15 can
contain 10 bits and that's it?..

TBD have implicit Immediate_SACK on BE=10 on size < 20 bytes as no space for TSN_HEADER
TBD every or just L=0 and non-zero Offset?

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|B|E|U|F|L|           Stream Sequence Number          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Stream ID     |     Offset, 1/2/3 bytes (20 bits max)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  User Data Left Length, VarUInt32  /  Block Length, VarInt15  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Control/Length|UserPart Len 1K|                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
     /                                                               \
     \         Control and/or User Data, at least 1 byte             /
     /                                                               \
     +---------------------------------------------------------------+
- and 4 bytes (20 bits) for TIMESTAMP when retransmission / no Packet Cache
TBD seems 20 bits not enough, put in Control Data? but would not be _same_
chunk for AUTH...

TBD Total Length, or Remaining Length? same size on > ~8 Mb though

 B E F L | Meaning      | Control | User Part | User Left | Block Length
=========+==============+=========+===========+===========+====================
 1 0 1 0 | first chunk  | Byte    | Byte, in  | VarUInt32 | Implied:
         | first block  |         | 1K units  |           | Control + User Part
---------+--------------+---------+-----------+-----------+--------------------
 1 0 1 1 | first chunk  | Byte    | None      | None      | VarInt15 
         | single block |         |           |           |
---------+--------------+---------+-----------+-----------+--------------------
 1 1 1 0 | single chunk | Byte    | Implied,  | VarUInt32 | None (known by
         | first block  |         | MUST be   |           | option length)
         |              |         | N * 1024  |           |
---------+--------------+---------+-----------+-----------+--------------------
 1 1 1 1 | single chunk | Byte    | None      | None      | None (known by
         | single block |         |           |           | option length)
---------+--------------+---------+-----------+-----------+--------------------
 1 0 0 0 | first chunk  | None    | Byte, in  | None      | Implied:
         | middle block |         | 1K units, |           | User Part
         |              |         | MUST be   |           |
         |              |         | N * 1024  |           |
         |              |         | (N > 0)   |           |
---------+--------------+---------+-----------+-----------+--------------------
 1 0 0 1 | first chunk  | None    | None      | None      | VarInt15
         | last block   |         |           |           |
---------+--------------+---------+-----------+-----------+--------------------
 1 1 0 0 | single chunk | None    | Implied,  | None      | None (known by
         | middle block |         | MUST be   |           | option length)
         |              |         | N * 1024  |           |
         |              |         | (N > 0)   |           |
---------+--------------+---------+-----------+-----------+--------------------
 1 1 0 1 | single chunk | None    | None      | None      | None (known by
         | last block   |         |           |           | option length)
---------+--------------+---------+-----------+-----------+--------------------

   NOTE that User Part can be zero, meaning no user data in this chunk (thus
   maximum size is 255K = 261120 bytes), for low MTU when tunnel does not have
   HMAC - so having HMAC by TSN layer at end of block would mean delaying
   delivery control data to dispatcher until all user part received (may be
   just to find that it should be thrown away).

   NOTE that "single chunk, first block" case on very low MTU would have not
   enough space for TIMESTAMP option on retransmit if all length fields are at
   their maximum (e.g. 8 Mb left of 16 Mb message from previous incarnation),
   but Control Data is 0 or 1 bytes in length - forcing either single chunk or
   putting at least 1K of User Data. On 24-byte MSS with AUTH option, it is
   enough space for AUTH of single chunk, but if TSN Base is full 4 bytes,
   then retransmit without Packet Cache would fail to transfer correct
   Message ID. Implementations MUST ensure this case could never happen, and
   here is how: observe that if Offset in first block is non-zero, then this
   is a DUP of message from earlier association, and thus either:
   1) a Full TIMESTAMP option present before this chunk (big enough MSS), or:
   2) Control Data is in CBAR form bearing Message ID, so it has enough length
      to be split into "first chunk, first block" form.
TBD if 1 byte Control Data & Offset=0, still 13 bytes > 11 so what? put 1K user?

middle block, beginning chunk:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|B|0|U|0|0|           Stream Sequence Number          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Stream ID     |     Offset, 1/2/3 bytes (20 bits max)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |UserPart Len 1K|                                               \
     +-+-+-+-+-+-+-+-+                                               /
     /                                                               \
     \                  User Data, at least 1 byte                   /
     /                                                               \
     +---------------------------------------------------------------+

last block, beginning chunk:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|B|0|U|0|1|           Stream Sequence Number          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Stream ID     |     Offset, 1/2/3 bytes (20 bits max)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Block Length, VarInt15     |                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
     /                                                               \
     \                  User Data, at least 1 byte                   /
     /                                                               \
     +---------------------------------------------------------------+
--
  Итого, в 24 доступных байтах на минимальном MSS=24 в среднем случае:

    * 2 байта TSN Base
    * 2 байта заголовка опции (длина тела больше 15)
    * 4 байта постоянного заголовка чанка данных
    * 2 байта FSN / продолжения смещения блока (от 16 Кб до 4 Мб) 

  Остается 14 байт для собственно пользовательских данных. В пределе же при
  1 байте TSN и нефрагментированном блоке - до 17 байт при 24-байтном MSS.

4.5. ECHO: Heartbeat Acknowledgement / State Cookie

  Представляет собой просто копию данных, полученных в State Cookie при
  установлении ассоциации, либо в Heartbeat при дальнейшей работе, "как есть".
  Поскольку тот же Heartbeat может использоваться для замеров RTT, получатель
  (т.е. отправитель ECHO) НЕ ДОЛЖЕН его никак задерживать.

4.7. ADDR_CONFIG: Address/Path confiG (Remove/Add) Stream Data

  Переконфигурация адресов (путей) ассоциации производится отдельным
  дополнительным потоком, формат опции которого:

TODO переделать нахуй, ведь клиент может иметь эфемерный адрес каждый раз

TBD для клиентов внутри NAT и снаружи, если мы advertise проброшенный адрес -
как отличать, клиентский пакет пришел изнутри или на проброшенный? если у них
окажутся разные ключи - мы не расшифруемся

  Коды ответа:

    0 - операция произведена успешно (нет адреса)
    1 - ошибка: попытка удалить последний оставшийся адрес
    2 - ошибка: недостаточно ресурсов
    3 - ошибка: попытка удалить адрес, с которого пришел запрос
    4 - ошибка: запрещено администратором (нет авторизации)

  Номер последовательности для сопоставления запросов и ответов - просто
  счетчик, сбрасывающийся в 0 после достижения 15. Он, с одной стороны,
  позволяет, например, отправить несколько разных блоков запросов отправителю,
  а получателю ответить на них единым блоком. С другой стороны, ограничивает
  максимальное количество ожидающих в очереди неподтвержденных запросов на
  операции с адресами

TBD адресная арифметика 8, или полные 16?

  Поскольку стандартный механизм обеспечивает доставку, но не гарантирует
  ответ, применяется таймер T4-RTO. При ошибках формата - есть номера в
  опциях ERROR / ABORT. В остальном см. применимые части из RFC 5061.

  По умолчанию добавленные адреса находятся в состоянии UNCONFIRMED, см.
  описание опции HEARTBEAT и соответствующие секции RFC 4960 и RFC 5061.

TODO:
0x00A3          Association Aborted Due to Illegal ASCONF-ACK
атомы: переделать на длину 8 Кб строками-ид протоколов а-ля alias MQTT
добавить код конфигурирования tunaddr; не бандлить операции?
избавиться от sequence вообще? ведь 5.1.1 C1) всё равно об одном in-flight
проблема reorder стр. 27 и далее - делать ack на ack? 5.3.2 ?

TBD если клиент продолжает сессию, на сервере уже есть атомы её переменных
TBD а что с разрывами? атомы тоже QoS'ить надо?..

4.7.3. Atom / Feature names negotiation.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|1|E|0| SeqNum  | Msg |        Header VarInt          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Data...
     +-+-+-+...
     
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|1|E|1| SeqNum  | Reply/Err |RepSeqNum| Header VarInt |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Data...
     +-+-+-+...

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
     |TSN Layer|0|E|    TSN Offset   |  Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...


   0 - I_HAVE
   1 - C: InternAtom | S: Atom_Created TBD just set branch atom.0 as req?
   2 - GetAtomName
   3 - ReleaseAtom
   4 - Get_Value - yours only
   5 - Set_Value - yours? both?
   6 - Value_Changed
   7 - Reserved

8 - OK
   9 - ERROR
  10..15 - Reserved

Header VarInt32:

        2                |2 1            |    1      |
        9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Length, valid if E=0             |C|Septinovile|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  C - CRC24 present, add 3 to Length
  Septinovile - if not NULL, prepend CBOR Tag 40 with dimensions

   This format allows for messages of up to 8 Mb in length, which is intended
   mainly for ability to store compression dicitionaries. That is, 32-bit
   implementations MUST support leaf value bytestrings of 32768 bytes in
   length (maximum Deflate dictionary size) and 64-bit implementations MUST
   support leaf value bytestrings of 112640 bytes in length (default zstd
   dictionary size), plus other row columns overhead (depending on negotiated
   tree depth). Following SSH tradition, maximum size in 32-bit case is
   arbitrarily defined to be 34000 bytes, so maxumum row overhead fits in one
   1280-byte MTU packet.
TBD zfs_btree 4096-(16+8*129)=3048 -> 1014 + 2 bytes length
TBD sys/cddl/contrib/opensolaris/uts/common/fs/zfs/range_tree.c

  I_HAVE - байтовые строки с именами атомов как фич

      0               
      0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+-...
     |C|   Length    | Value of length + 1 bytes
     +-+-+-+-+-+-+-+-+-...

   C - Create / only-if-exists: BOOL
GetAtomName - 2 bytes = CBAR Atom ??? multiple?

TBD придется согласование максимального числа атомов, макс. вложенности дерева

-> если корень Septinovile на 9 корней и длина 0..6 -> 12+1=13 макс. путь,
ну в 19 байт так влезет

!! при MSS=24 же чанк AUTH, значит на BE=11 реально есть только 14 байт,
включая заголовок опции, т.е. 12 байт на заголовок + путь максимум
-> продумать формат GetBulk/GetNext - там что, дублировать пути/длины values?

algorithm.HMAC.SHA1: true
algorithm.HMAC.SipHash.0.0: 2
algorithm.HMAC.SipHash.0.1: 4
algorithm.HMAC.SipHash.0.length(2): 8	# bytes, for CBOR's 0..23
algorithm.HMAC.SipHash.1.0: 4
algorithm.HMAC.SipHash.1.1: 8
algorithm.HMAC.SipHash.1.length(2): 8
algorithm.HMAC.HalfSipHash.0.0: 2
algorithm.HMAC.HalfSipHash.0.1: 4
algorithm.HMAC.HalfSipHash.0.length(2): 4
algorithm.compress.deflate: true

TBD in addition to Atom, need 'symlink' or 'mount' type with OID Path - to be
e.g. able to persistent store only 'session.*' and compression dictionaries
refer to that subtree

TBD команда ResolvePath: нулевой байт как у обычного пути, но N задает,
сделать ли заодно ответ на Get этого же пути, а длина не в байтах, а в
элементах - при старшем бите 1 это атом, иначе длина и потом сама строка,
причем при длине, равной 1, это на самом деле не строка, а индекс
- потому что MUST NOT однобайтовые строки для атомов

-- variant SQL:

take record format from SQLite, somewhat modified

TBD for sublists with tree of streams, even 64 Kb is not enough - use
Septinovile as 7 or 9 to be multiplier of usual length field?
-> possible variant: VarUInt32 with Hi 19 bits for length, 5 for root and 6 by
   scheme above (means 5 levels max after root)
-> or still 5 bits for 4 levels, so one bit of root can encode Atom length
   in single byte (6 bits)
 TBD make length aligned to 4 bit? 18 len / 7 roots - this is too many roots...
   -> 22 len, 3 root, 5 as above (4 levels) = 8 roots and 4 Mb
      ...but this is almost the same as byte in variant SQL 2, always having
      length <=63 in 2 bytes
      -> put Root in LSB, invert 0/1 - then only long paths will have 2 bytes
TBD if CBOR (not CBAR) then 1 bit if GHC
  TBD do GHCompress of entire message instead of separate each row? so paths
  could be compressed, too, while allowing for yet-unknown atoms
  TBD keys sort order
  - if CBOR, each atom is usually prefixed by CBOR byte, so each segment lengthened
    -> put in compression opcodes for just atom and CBOR-prefixed atom?
       - or may be use CBOR Tags 25/256 directly in parser?
	 -> seems no, these have rules for increasing lenghts, but atom
            numbering is independent

if BE=10, then VarUInt32:

        2              |  2 1          |      1        |
        9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |a a a a a|b b b|c c c c c|d d d|e e e e e|f f f f f|g g g g|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       thin = 0b0bbbdddfffff + 1 (1..2048 in 11 bits)
       wide = 0b0aaaaaccccceeeeegggg + 1 (1..512K in 19 bits)

else if BE=11: just byte with pairs (1..256 pairs)
TBD what if Get? some cases always 1 pair
TBD not pairs, but entries? for triplets with last time e.g. for queries from last session,
also "want reply" bit 

TBD atom should be separate commands coz compression will try to use themselves to compress

TBD Bitmap Ranges for GetAtomName?

TBD RFC 8746 Multi-dimensional Array in CBOR
   uint16_t a[2][3] = {
     {2, 4, 8},   /* row 0 */
     {4, 16, 256},
   };

   <Tag 40> # multi-dimensional array tag
      82       # array(2)
        82      # array(2)
          02     # unsigned(2) 1st Dimension
          03     # unsigned(3) 2nd Dimension
        86     # array(6)
          02      # unsigned(2)
          04      # unsigned(4)
          08      # unsigned(8)
          04      # unsigned(4)
          10      # unsigned(16)
          19 0100 # unsigned(256)

          Figure 2: Multi-dimensional Array Using Basic CBOR Array
and also Tag 41

TBD race conditions with atoms & other session - use RFC 5661 Section 2.10.6 ?
-> no, ReleaseAtom message from both sides, like refcount/semaphore
  - 19.06.25 02:40 if both sides just have independent CBAPT interpreters,
    this is of less concern (directions independent), but synchronization
    with other *our* streams still a problem: see 26.09.25 (RFC 9204 2.1.3),
    and even if that solvable for control streams (put all atom-dependent to
    one internal stream? use timestamps as barriers?), what about e.g. PPID
    as Atom in ordinary user data stream which gets retransmitted (DUP) after
    reconnection?

TBD for sublists with tree of streams, if array[index]=parent then compact?
- no, we need ordering like "first substream" for e.g. EXTENDED_DATA_STDERR
- make it also #6.40 for reply_to/reply_first/reply_next in 2nd Dimension?
  - this means linked lists thus no gaps possible, so what to do when reparent
    of stream in the middle? numbers for others will shift, is it ok?
    TODO study again RFC 4254, SST and HTTP/2 priorities
  - but is it needed? keeping array N*N streams is bad for constrained implementations

TBD make hash keys bytestrings, e.g. instead of
   ["algorithm", "HMAC", "SipHash", 0, 0] => 2,
make this indefinite-length array, strip first 0x9f and final 0xff, and make it
   "\x49algorithm\x44HMAC\x48SipHash\x00\x00" => 2,
for both string-only hash keys support and memcmp() sort order (of min prefix
and if equal then shorter length is less)
- this conflicts with Sep2023 CBAR where atoms inside CBOR swith to BLOB
  loosing efficiency
  - do such string convertation only in implementation, not on wire? with
    #6.40 it's not map anyway so languages with string-only hash keys support
    not a problem
    - 15.01.25 21:26 see 14.01.24: if the entire tree is just CBOR document
      itself (with path-addressable leaf marked with some tag, so trying to
      set intermediates will give error), then sort order will be achieved
      automatically for arrays and for maps if they are implemented by already
      sorted structure (B-tree, RB-tree); this also naturally solves repeating
      paths problem for GetBulk/GetNext as in CBOR itself they are not
      repeated - just need to somehow solve "truncated"/"restart from" problem
      and register a tag for "symlink"/"mount" a subtree (being a path). So,
      #6.40 will be needed only for Set_Value with multiple values at once
      ...or even without #6.40? just `perl -E` example from `cbar.txt` enough?
      well, if go further to `sysctl()` analogy then notice single `sysctl()`
      has both get and set in one syscall determined by non-NULL arguments
      (this nicely fits to RPC calls (SYSCTL_PROC) as "set" has arguments as
      input, but also must return answer), so #6.40 may be used to emulate a
      series/batch `sysctl()` for multiple values in one message
      - if truncation is done as bytestring then concatenate with next
	bytestring, this is a DoS vector... even more, any bulk requests may
	be a DoS vector
      - what about enumerating just names, `sysctl -N` ? may be useful when
	values are large... answer with some placeholder/"absent" tag instead
	of value? return estimated size of value instead of value (again
	tagged)? again may be unnecessary load on server
	- no, no "estimated" - RPC calls will not know it without call
      - #6.40 may still be needed if we ever support additional columns, like
	type or description... but do we really need in L4/L5 protocol,
	not application protocol? if only for debug purposes
      - allow intermediate nodes be also settable if (yet another) special tag
	on node allows it? e.g. to set a subtree with features or dictionaries
	at once? use this instead of bulk Set_Value?
	- if we don't need additional flags, then same (single) tag may be
	  used for both intermediate and leaf values... or we need, for R/W
	  and SYSCTL_PROC?
      - for "symlink"/"mount", abuse tags 110/111/112? it will even conform to
	RFC 9090 if strings in path for map keys will be text strings
	(Major Type 3)
        - 19.06.25 02:30 just use CBOR Pointer?
      - what to do in GetBulk/GetNext/subtree for SYSCTL_PROC nodes? put
	a placeholder? TODO look into what `sysctl -a` does for such procs
  - then string-length bytes also should be replaced in implementation, so
    that "assoc" sorts after "algorithm" (would be opposite by length), see
    also https://sqlite.org/src4/doc/trunk/www/key_encoding.wiki
    - an alternative to simplify memcmp is to have header and body as in
      SQLite3 record format, where key to compare is at body... again old CBAR?

https://sqlite.org/src4/doc/trunk/www/varint.wiki has memcmp-ordered varints
see also in Appendix I

TBD 28.08.24 as seen in NetBSD, it has different query scheme instead of
GetNext; also, instead on Get and Set - have one call like sysctl(old, new)?
but influences notification Value_Changed - make a "subscription" of once
queried values?
- subscription needs to refine which portions of tree are shared (must be same
  on both sides) and which are not
- NetBSD's CTL_QUERY returns array of just immediate children - may be
  ineffective (chatty) when want to get many small subtrees
- yet another possibility: also add sysctlbyname()/sysctlnametomib(), but
  session-stable `rowid` instead path array
  - it will be different on each side for most entries, and problematic for
    implementations to have two trees

TBD 14.01.24 02:50 reading EBML [RFC 8794] - it has paths and Elements of
unknown size: what if Sesctl tree of elements is just like an indexed view to
file, mmap window?
<<Only a Master Element is allowed to be of unknown size, and it can only be so if the `unknownsizeallowed` attribute of its EBML Schema is set to true>>
-- so the entire sysctl tree may be just CBOR tree with some nodes being
accessible by path, but where leaf could be complex CBOR value as well;
attributes and SYSCTL_PROC could be represent by CBOR tags in such tree
- 09.04.25 14:00 reading (referenced by CBOR STD) MSDTP [RFC 713] - it did not
  had maps, but it (already 49 years ago!) had something similar to YAML tags
  and STRUC's had their size in bytes - that is, easy to navigate in file or
  database (so EBML just added streaming, like CBOR; also indexing reminds of
  PBMFS) and it also had USTRUC's (for "uniform") where type is single for all
  e.g. for strings - CBOR added tags 64-80 after several years; and most
  surprising for 1976 year, it allowed up to 128 bytes for *size* integer -
  that is, up to 2^(128*8) byte (while Universe has ~10^80 atoms ~= 3*2^264)
  strings in length!

TBD 09.04.25 ~23:10 radical idea: as CBAR/CBAPT is targeted to RPC calls, what
if to pass arguments to command calls in it, instead of "variable tree" with
SYSCTL_PROC as in older SNMP/sysctl? Moreover, if to change most internal
streams to CBAPT ? May be even some of regular user data streams structure?
Of course, they will retain current bit-crunched formats for efficiency, but
these will be for pack/unpack/binary scan commands so can be extensible
- 28.05.25 19:30 actually this doesn't buy much: the commands nevertheless
  must be organized to some hierarchy - be it Some::Namespace::Cmd or
  assoc.retransmax is not structurally different. However, it allows thinking
  like Tk widget hierarchy or method calls on object beyond just get/set, e.g.
  `Algorithm.HMAC listchildren`. In fact, the only PRO of single CBOR document
  is ability to get many values in bulk, saving round trips - but only if
  "truncated"/"restart from" problem is solved, and it doesn't play well with
  nodes which are RPC procedures instead of pure data. Ironically, CBAPT's
  design goal (next after packing) is also saving round trips in RPC calls...

TBD 26.09.25 RFC 9204 "QPACK: Field Compression for HTTP/3":
<<2.1.3. Avoiding Flow-Control Deadlocks

Writing instructions on streams that are limited by flow control can produce deadlocks.
A decoder might stop issuing flow-control credit on the stream that carries an encoded field section until the necessary updates are received on the encoder stream. If the granting of flow-control credit on the encoder stream (or the connection as a whole) depends on the consumption and release of data on the stream carrying the encoded field section, a deadlock might result.>> -- do we have same problem when internal streams window is always separate? at least MUST note this



TODO

4.8. HEARTBEAT: Heartbeat Request

  Является "пингом" - просто последовательностью байт, никак не
  интерпретируемой получателем, которую он просто должен отразить обратно
  "как есть" опцией ECHO. Применяется для поддержания соединения, пока нет
  пользовательских данных, для проверки "живости" других адресов (путей) и
  для точных замеров времени RTT любой из сторон. Поскольку всё это
  параметры конкретного пути / адреса / туннеля, получатель ДОЛЖЕН ответить
  на HEARTBEAT опцией ECHO по тому же пути, по которому был получен запрос.
  Для обеспечения различимости и точности РЕКОМЕНДУЕТСЯ, чтобы длина данных
  в HEARTBEAT составляла не менее 8 уникальных байт каждый раз.

  NOTE: эти 8 байт MUST NOT be timestamp but truly random, as there is
  TIMESTAMP for timestamps

  Подробнее о работе с HEARTBEAT для проверки доступности адресов (переходе в
  состояние CONFIRMED) см. в секциях 5.4 и разделе 8 в RFC 4960.

4.6 TODO FORWARD_TSN

проблема: для 256 ordered и unordered может занять 1024 байта, а еще битмапы

ну допустим для сверхнизких MTU используем FRAGMENT, но и 512 байт таки мало

предположим, policy PR был на 1 ретрансмит, и уже улетело 5 ordered-блоков и
в 2 из них дыры -> abandon возможен промежуточных и на ordered, а на Unordered
тем более
-> надо не просто largest stream sequence number in this stream being skipped
  как в RFC 3758, но и Bitmap еще и номеров блоков?

TBD может разделить FORWARD_TSN и ABANDON_BLOCKS ? а второе сунуть
в INTERCHUNK_STREAM_CONTROL ? раз уж CANCEL_BLOCK есть...
-> в принципе, это согласуется с DUP в начале сессии в нём, и еще ж rewind
номеров тоже нужен, без реальных пропусков TSN

TBD что тогда с 3 битами в TSN делать? Reserved? матчинг номер операции под
ABANDON_BLOCKS ? их число после?

variant: не финальные номера и битмапы, а 1-4 байта на каждый TSN, отсылаясь
при необходимости на предыдущий в этом чанке - тогда сколько в один чанк
влезет, на столько Cumulative TSN и подвинется
одна запись:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 0|   TSN Layer   |U|Stream Sequence Number |   Stream ID   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2      
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|Dlt|U|Stream Sequence Number |   Stream ID   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1           
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  I = Increment SSN by 1
     |1 0|I|Look Behind|  TSN Layer  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-- SQL variant

VarNibbles triples (Delta, SSN, SID), where:
Delta=TSNDelta<<3 + U*4 + is_SSN_delta*2 + is_SID_delta
SSN = is_SSN_delta ? delta : absolute SSN
SID = is_SID_delta ? delta : absoulte SID

or,
SID+SSN = 20 bit, then take VarNibbles on this sorted list
TBD 5 nibbles = 20 bit, need 1 bit for U and maybe 1 bit for SKIP vs ABANDON

-- SQL variant 32

sorted list of 31-bit numbers SID|SSN
first 4 bytes = U+SID+SSN of first gap, then deltas as VarNibbles

-- /SQL variant

TODO

TBD сразу по обоим FORWARD_TSN и INTERCHUNK_STREAM_CONTROL:
1) DUP - просто таймштамп и всё
2) FORWARD_TSN - набор на каждый пакет
3) ? ABANDON_BLOCKS - отправлялись, но теперь не будут - вроде дублирует 2
4) ? SKIP_BLOCKS - не отправлялись, и уже не будут - битмап? +один range <8ffh?
5) ? REWIND_BLOCKS - просто set:=новый номер, при reset или перед DUP
6) HMAC - индивидуальный поток, в т.ч. channel, с промежуточным значением & new
7) HMAC - дефолтные значения для многих потоков, в т.ч. слоты Unordered
4 и 5 возможны только блоков, 5 только для ordered

[RFC 6525] описывает еще запрос на резет входящих (в 0, Unordered не описаны,
явно встречается только про SSN 0 for its first ordered message) и ошибки и
статус типа in progress

TBD с точки зрения MQTT, что ACK/REC/COMP, что cancel, что ABANDON, что skip
конкретного - есть операции над одним и тем же идентификатором пакета, просто
лишь для skip/forward/cancel мы знаем, что он в этой же ассоциации, и потому
может сэкономить на таймштампе в id; а HMAC же - операции на стримах, как и
window adjust/set - может, объединить эти стримы-то?

но для Unordered не нужен ни таймштамп, ни QoS, чисто номера

или переразделить - например, message control vs stream control, и window тоже
засунуть во второе, просто в обоих будут операции my vs your
- тогда FORWARD_TSN можно сделать просто битмапом TSN-ов таки, что приведет к
  куда более быстрому схождению
- skip/rewind тогда будут отличаться по критерию - создавался ли ever таймштамп
  у сообщения; в противном случае это свойство стрима

TBD о приравненности QOS_ACK к window adjust (см. ниже) - и нужен ли,
действительно, window в блоках? по лимиту памяти скорее байты
- разве что для lock-step protocols? хотя есть ли такому разница, сколько там
  в очереди в сокете сидит?
  - таки да, то есть нет:
After user level consumes message from socket buffer and before it processes
it to issue ACK, it may pass time during which window is already open by size
of message, so peer could send us more.

TBD what if ABANDON for ordered with timestamp goes when (B) fragment (with
this timestamp) was not received?
-> so for this SSN is also, and thus it MUST be within SSN window, and
   timestamp within 2*MSL window (but MSL as defined on *this* tunnel protocol)

для ABANDON_BLOCKS таймштамп дельта от своих, они-то монотонные, а для
встречных сложнее

TBD REWIND_BLOCKS is not needed due to different space - MsgID is by
Timestamp, SSN is low level to put it in API

TBD make (application) stream error codes also in STREAM_CONTROL 

4. TODO INTERCHUNK_STREAM_CONTROL: управление потоками

Partial Reliability
здесь компрессия, auth для ordered/каналов - чтобы не тратить в каждом чанке

байт ширины, заголовок с операциями, Stream Table Rows - дельта номера стрима
по сумме из 512 (ordered, Unordered, каналы, группы), биты присутствия поля -
как туплы в SQL-таблице
TBD или без групп, а 2 байта "номер чанка / номер канала"?

TBD мож резет компрессии/HMAC тоже в опкод FORWARD_TSN ?

TBD фрейминг DUP START/END блоков из предыдущей сессии с таймштампами?
TBD т.к. всего 2 байта DUP, надо или здесь суметь передать доли, или
распрощаться с микросекундами
-> DUP is in CBAR instead

-> вместе с с базовым таймштампом передаем FracL, в этих долях и будут байты
   DUP, а сами по себе они безразмерные int'ы просто

     |Auth HMAC's AlgParKeyLen (opt) |Length, if E=0 |    Atom or    \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
TODO

4.17. QUEUE_READ_ACK: Blocks consumed by ULP

  Извещение отправителя о том, что более высокий уровень успешно прочитал
  и обработал блоки с указанными номерами. Позволяет реализовать аналог QoS из
  MQTT, когда имеется сессия с хранением состояния, и необработанные
  получателем блоки будут посланы заново в случае обрыва и переустановки
  соединения. Формат опции:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|X|B|E| Block Len/Ofs |Strm ID| Stream Sequence Number|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Strm ID| Stream Sequence Number| 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+...

  Здесь X - просто бит расширения поля Block length / Offset, если оно
  присутствут, то есть, максимальный размер сообщения с подтверждением
  обработки составляет 511 байт.

TODO:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|L|B|E|  Stream Sequence Number | FSN | Blk Len if E=0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Data...
     +-+-+-+...

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|Op |Stream ID|     Stream Sequence Number    | ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+...
     |1|Op | Stream Sequence Number  | ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+...
TBD или нет, не 0/1, а еще байт Bitmap для диапазона добавить

  Далее в данных идут идут пары по 2 байта, номеров потока и блока в нём,
  которые отправитель может освободить, т.к. получатель их прочёл. Это
  касается только обычных блоков - ни Unordered, ни TCP-like потоки таким
  образом не подтверждаемы.

  Получателю данных (т.е. отправителю этой опции) РЕКОМЕНДУЕТСЯ отсылать
  подтверждение только тогда, когда данные действительно были обработаны
  вышележащим протоколом, а не просто полностью прочитаны им из сокета.
  В случаях, если это невозможно (например, реализация в ядре или разных
  процессах и т.п.), можно применить, например, аналог Nagle с задержкой
  отправления подтверждения после момент завершения чтения, или ожидания
  следующего вызова в muSCTP, если известно, что читатель однопоточен, и т.д.

TBD если номера строго последовательны, то юзать максимальный чтоб убрать StrmID?
но тогда для QoS может понадобится код Ack/Rec/Rel/Comp, а если юзер читал
блоки не последовательно?..

   0 - QOS_ACK
   1 - QOS_ACK_BITMAP
   2 - QOS_REC
   3 - QOS_REC_EXT
   4
   5
   6 - QOS_REL
   7 - QOS_COMP

TBD в MQTT есть флаг DUP, сделать аналог для ретрансмиченых блоков в новом
соединении из старого - либо здесь, либо в настроечном
TBD или отфреймить их в STREAM_CONTROL

TBD для деревьев стримов - посмотреть SST и dummynet

для блочных, VarUInt32 - ниже 32768 в блоках, выше - в байтах

TBD у нас же могут быть дупы в сессии с прошлой ассоциации, значит, надо
передавать в QoS и таймштамп тоже, т.е. абсолютный идентификатор сообщения

TBD поскольку PUBREC освобождает хранение самого сообщения, его роль начинает
играть PUBREL, а значит, для них тоже надо предусмотреть DUP 1/2 байта? т.к.
мы объединяем пачку под одним SSN

TBD приравненность QOS_ACK/QOS_REC к MESSAGE_WINDOW_ADJUST +1 - всегда ли? а
если пайплайнить? мб от имплементации зависимость?
-> скорее всегда, т.к. если блоками меряем, то на низких окнах приложение же
   еще не обработало, а значит, пайплайн даст увеличенный расход памяти

TBD наверное режим MESSAGE_WINDOW_ADJUST блоками должен быть взаимоисключающ
с байтовым, а то так придется дублировать командой MESSAGE_WINDOW_SET сколько
стало байт

TBD или нет? мы же номера передаем, отправитель знает его размер, это только
для QoS=0 простой add...

TODO unordered имеют общее окно в своем стриме с ordered

формат: 4 бита номер команды, 4 аргумент
* для window в аргументе передаем длину bitmap ranges, потом 1 байт первого
  стрима, потом bitmap ranges - какие стримы, потом на каждый VarUInt32
* для QOS_ACK и QOS_REC аргумент + 3 байта = базовый таймштамп, потом туплы:
  - VarUInt32 как дельта в микросекундах от предыдущего
    TBD мож сократить как-то? и в таком же формате DUP ?
  - 1 байт номер стрима
  - 2 байта номер в стриме
* для QOS_REL и QOS_COMP такой же формат, только отсутствует номер стрима
Rationale: для QoS больше 1-го параметра, просто так дельту стрима не сделать

вариант - заголовочный байт, в котором есть просто инкремент таймштампа, без
аргумента, и указание на 1/2 байта DUP, идущих следом

0 - просто инкремент, до 127 секунд TBD может Shift и/или доли?
10 - 6 бит инкремента секунд, дальше 1 байт
11 - 6 бит инкремента секунд, дальше 2 байта
TBD а если всё в 1 байт и уложилось бы? может, VarInt22 ?

TBD 2 байта DUP мало же, если микросекунды - не влезет
-> если INTERCHUNK_STREAM_CONTROL сможет передать доли до 1/16, то можно

следующий вариант: аргумент 4 бита есть FracL, в каких долях будут инкременты,
и их просто как VarInt22, в заголовке же полные 4 байта секунд
TBD подумать, если не влезает - просто 3 байта максимального значения как
джамп без аргумента? или пусть в другую команду идёт, благо SSN до жопы?

TBD а зачем SSN все 16 ? ведь и QOS_REL и QOS_COMP достаточно один раз, если
это просто таймштамп полный, то после 20 бит остается 12 - вот тебе и 4 на
номер команды, а для window можно в отдельном байт 4 бита на длину bitmap
ranges и 4 на старшие 4 первого стрима
TBD а FracL тогда где? - видимо, частью базового таймштампа?
TBD может не 4, а до 5 байт, и кроме FracL еще длину? как PBITS/NBITS
TBD не, проще, 4 бита FracL, 2 бита Quarter of Sec, 2 бита - сколько байт
длины базового таймштампа, недостающие старшие берем из этого пакета

TBD частым случаем будет только один в ACK/REL, завести ему другой формат?

-- variant 9:

Если снижаем SSN до 12 бит и долю до 10 бит (миллисекунд), то FracL не нужен:
в QOS_ACK/QOS_REC записи по: 8 бит номер стрима, 12 бит SSN, 4 бита на дельту
таймштампа Хаффманом - возможны еще 1..2 байта, т.е. 18 бит максимум, это аж
до 256 секунд

для QOS_REL и QOS_COMP имеем аналогично, но без стрима, сразу SSN из потока
QoS, потом 10 бит миллисекуд и 2 бита длины для секунд - 1..4 байта, итого
максимум 7 байт

-- /variant 9

TBD CBAR ?

-- variant VarSextet:

   Chunk format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSN Layer|B|E|RemLength, if E=0|    Stream Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    tv_sec Subtract, VarUInt32                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                     Commands, VarSextets                      /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Remaining Length field, present if BE=10, uses S bit as high bit (if
   BE=11 then S bit MUST be ignored) and specifies length after first chunk:
   for example, Remaining Length equal to 511 in B-chunk with 256 bytes after
   header means 768 byte message in total. If E is set, then bit S MUST be
   ignored, that is, Stream Sequence Number is byte-aligned as usual and
   started from bit 8 in such case.

   The tv_sec Subtract header field is subtracted from tv_sec part of timestamp
   of TSN chunk to get BaseTime value used in subsequent delta-coding of
   message IDs. As VarUInt32 is limited to 30 bits, that means that on minimal
   MSS (without space for DUP TIMESTAMP) session can not be interrupted for
   more than approximately 34 years.

   Next follows VarSextets array with operation codes till the end of chunk.
   It has no explicit length specified and MUST be padded with zero bits - in
   case of 6 bit padding, full sextet, it would be interpreted as switch to
   stream 0, which is harmless.

   After decoding, integers are read from array one by one, command integer
   contains an immediate argument inside itself and may have zero or more
   arguments (also integers, of course), which are then consumed from array
   depending on command.

   General command (opcode) integer format:

        2         2 1                 1         
        5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Immediate argument             |Command|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Commands and meaning of their immediate argument:

     N | Command       | Immediate argument     | Explicit argument count
     ==+===============+========================+========================
     0 | SWITCH_STREAM | Stream number          | 0
     1 | WINDOW_ADJUST | Set/Adjust/NULL/Parent | 0 or 1
     2 | QOS_REJECT    | ErrCode + MsgID low 2  | 2
     3 | QOS_PARTIAL   | LengthK + MsgID low 2  | 0
     4 | QOS_ACK       | Message ID low 2 bits  | 2
     5 | QOS_REC       | Message ID low 2 bits  | 2
     6 | QOS_REL       | Message ID low 2 bits  | 2
     7 | QOS_COMP      | Message ID low 2 bits  | 2
     8 | SKIP_BLOCKS   | (N << 3 ) + U          | N+1

TODO cmd PLEASE_OPEN_WINDOW

   Other command numbers are reserved and MUST be treated as errors.

   The SWITCH_STREAM command does not need to correspond to real stream - it
   merely updates current variables of parser, in pseudocode:

     cur_stream := Immediate argument
     cur_tv_sec := BaseTime

   This stream number is later used not only for stream-operating commands,
   but also to obtain full Message ID in QoS commands, by using low 10 bits of
   cur_stream variable.

   QoS commands have the following common format, drawn with arguments
   as 3 integers (26 signinficant bits each) after decoding:

        2         2 1                 1         
        5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Error code / Saved Length       |Low|Command|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    tv_sec Delta                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   tv_usec as is                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message ID is obtained by pseudocode:

     cur_tv_sec += tv_sec Delta
     msgid.tv_sec := cur_tv_sec
     msgid.low32  := (tv_usec << 12) | ((cur_stream & 1023) << 2) | Low

   Error code is currently used only in QOS_REJECT command, in QOS_PARTIAL this
   is Saved Length field.

   Note that cur_tv_sec is reset to BaseTime at each stream switch, so sender
   implementation is simplified to sort Message IDs only inside one stream.

TODO reject codes

   QOS_PARTIAL serves for retransmission of large messages after restoring
   broken connections, it's immediate argument specifies which part of long
   message with this Message ID is successfully stored to stable storage,
   in units of 1 K bytes (1024 bytes). This is used after connection restored
   to save several round trip times which otherwise would be needed to reject
   transfer started from very beginning and query remote from which offset
   to resume, and, more importantly, buffers / congestion window (scarce
   resource at connection start) bloated with already seen data.

   QOS_ACK, QOS_REC, QOS_REL and QOS_COMP behave as similarly named ones in MQTT
TODO copy behaviour description here from MQTT 5.0 standard

   WINDOW_ADJUST command have the following common format, drawn with argument
   as two integers (26 signinficant bits each) after decoding:

        2         2 1                 1         
        5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Arg19                |SubOp|Command|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Arg26                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Explicit argument, named Arg26, is not always present, exact operation,
   including possible re-parent of stream, is defined by SubOp in the
   folowing table:

   SubOp | Description           | Arg26 | Pseudocode
   ------+-----------------------+-------+--------------------------------
      0  | Window, Set NULL      | No    | window := NULL
      1  | Window, Adjust, short | No    | window += Arg19
      2  | Window, Adjust, long  | Yes   | window += (Arg19 << 26) | Arg26
      3  | Window, Set, short    | No    | window := Arg19
      4  | Window, Set, long     | Yes   | window := (Arg19 << 26) | Arg26
      5  | Window, Please Open   | No    | read(cur_stream, Arg19)
      6  | Reparent, see below   | No    | See below
      7  | Reserved for future use, MUST be treated as error

   For reparent operation, the Arg26 is not used and Arg19 is further
   subdivided into 

        2         2 1                 1         
        5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Weight  | Parent Stream ID  |Splice |1 1 0|Command|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Splice argument, named after Perl function splice(), defines where
   cur_stream will be put in hierarchy:

   0 - Set Parent to NULL
   1 - Exclusive flag
   2 - push
   3 - unshift

TBD less bits for splice? move parent to separate command = more bits for future?

TBD move weight to config, as it is mass operation so will better compress in CBAR?

TBD push/unshift bit for reparent & excl in Shift? weights in Hi 5 of Arg15 ? 
|    An exclusive flag allows for the insertion of a new level of
|    dependencies.  The exclusive flag causes the stream to become the
|    sole dependency of its parent stream, causing other dependencies to
|    become dependent on the exclusive stream.  In the previous example,
|    if stream D is created with an exclusive dependency on stream A, this
|    results in D becoming the dependency parent of B and C.
| Belshe, et al.               Standards Track                   [Page 25]
| 
| RFC 7540                         HTTP/2                         May 2015
|                          A
|        A                 |
|       / \      ==>       D
|      B   C              / \
|                        B   C

   Note that maximum possible values for window can be up to 45 bits wide 
   (Arg19 as most siginficant bits, then Arg26 as least significant bits)
   with long argument. As 32-bit implementations have to keep their
   window as signed value, sender MUST put such values that, after
   calculations, window will not exceed 2^31-1 bytes, unless an extension
   was negotiated at INIT stage.

   Finally, SKIP_BLOCKS command is used to report to receiver that particular
   Stream Sequence Numbers of DATA chunks are abandoned, either by Partial
   Reliability procedure or as a result of previous QOS_REJECT request from
   receiver.

        2         2 1                 1         
        5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | N (number of arguments minus one) |ChTyp/U|Command|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Stream Sequence Number of first skipped block   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Arg1                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Arg2                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                   \
       /                        ...                        /
       \                                                   \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        ArgN                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The ChunkType/U field is mainly for future extensibility, only two
   values are defined now, all other MUST be treated as error:

   0000 - chunk USER_MESSAGE, Ordered
   0001 - chunk USER_MESSAGE, Unordered

   Then N field gives how many arguments are taken, after mandatory argument,
   which equals to Stream Sequence Number of first skipped block in this
   stream.

   Each argument integer after the SSN has the following format:

        2         2 1                 1         
        5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Delta to next SSN (after bitmap)     |Bitmap |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bitmap field tells state of first four consecutive numbers (from MSB
   to LSB, 0 is not skipped block and 1 means skipped) after point
   where previous argument left off, and then Delta is the number to add to
   them to get number of next skipped block.

   For example, let's say skipped block number from previous step (or first)
   was 1000. Then bitmap says about blocks 1001, 1002, 1003 and 1004, and
   Delta + 1004 will be number of next skipped block. Note that Delta could be
   zero, then current block number doesn't change (e.g. at end of arguments).

   Longer example:

        2         2 1                 1         
        5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  3                  |0 0 1|1 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      1000                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   13                      |1 1 0 1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    1                      |0 0 0 1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    0                      |0 1 0 1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Here, block 1000 skipped by argument zero, first argument skips
   blocks 1001, 1002, 1004, 1017, second 1021, 1022 and third 1024, 1026.

   Five decoded integers of this example are serialized into following
   VarSextets (dot delimits prefix for clarity):
   
   101.101 110000             <- 3*128+24-40 = 368, prefix 0b101
   1101.00 001111 101000      <- 1000 need 14 bits, prefix 0b1101
   101.010 110101             <- 13*16+8+4+1-40 = 181, prefix 0b101
   0.10001
   0.00101

   Also note that inside one stream all skipped blocks MUST be within allowed
   SSN range, in particluar, this means counter MUST not exceed allowed number
   of SSN's in flight, that is, 2^(SSN width)-1 from the lowest SSN.

TODO

4.11. LINK_INFO: Informing about SRTT/RTTVAR, cwnd and other path parameters.

  Имеет смысл от клиента к серверу для информирования того о замеренных
  им параметрах конкретного пути. Нужно для оптимизации ресурсов на сервере -
  оценке, когда долгое отсутствие пакетов от клиента уже вероятно означает
  обрыв соединения. Для тех AF, где сервер может самостоятельно инициировать
  пакет (например UDP), позволяет серверу рассчитать время, когда это делать,
  с учетом того, что клиент мог отправить встречный пакет сам.

  Формат опции, 4-7 байт:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |ShftS|    SRTT's mantissa      |ShftV| RTTVAR's mantissa |cwndf| 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     . cwnd low (opt)| MSS C2S (opt) | MSS S2C (opt) |
     ..+-+-+-+-+-+-+-+...+-+-+-+-+-+-+...+-+-+-+-+-+-+

    * ShftS - сдвиг SRTT
    * ShftV - сдвиг RTTVAR
    * cwndf - формат cwnd / наличие еще 1 байта

   Values of SRTT and RRTVAR are in milliseconds and are encoded with usual
   "mantissa+shift" way. One can notice that this format allows for unusually
   high values - more than 15 minutes. This is due to possibility to have e.g.
   a chain of HTTP proxies along the way, each with it's own timeouts.

   SRTT and RTTVAR are transmitted separatedly (instead of combined RTT) for
   being able to gather statistics on different paths andf potential
   possibbility of adaptation.

  С учетом того, что передается время, которое не может быть нулевым, и для
  сервера не является критической точность, значение передается дополнительно
  сдвинутым на единицу, которая прибавляется после декодирования, т.е. формула
  декодирования:

    RTT = (RTTmant << (RTTSh + 1)) + 1

  например, при нуле в обоих полях (сдвига и мантиссы) итоговое значение будет
  равно 1 мс, а при 1 в обоих полях - значение составит 5 мс.

  При overflow значения формата (особенно, как видно, для RTTVAR отведено
  меньше бит) просто записывается максимальное значение (все единицы).

TBD cwr?

TODO some bits for congestion control algo, as in DCCP
especially TCP-Friendly Rate Control for Small Packets (TFRC-SP) [RFC 5622]

TODO bit for "ECN from you not trusted / disabled" (will be for some tunnel
types)

no need for "RTT spin bit" of QUIC - LINK_INFO could be just put under Shared Key ID = 0

 , 3-6 байт:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CCval |Flags|RTTsh| SRTT's mantissa |RTTVAR frac|cwndf| cwnd low (opt)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MSS C2S (opt) | MSS S2C (opt) |
     +-...-+-+-+-+-+-+-...-+-+-+-+-+-+

CCVal not needed? RFC 3448

TBD cwnd as VarOffset?
TBD extensions as VarSextets or CBOR ?

    * RTTsh - сдвиг SRTT
    * H - in Half seconds ?? TBD

   RTTVAR frac - 6-битное число формата en.wikipedia.org/wiki/Minifloat без
   дополнительных значений Inf и NaN, кроме двух (в строках старшие 3 бита,
   в столбцах младшие):

         ...000 ...001 	...010 	...011 	...100 	...101 	...110 	...111
   000...lim->0 0.125 	0.25 	0.375 	0.5 	0.625 	0.75 	0.875
   001... 1 	1.125 	1.25 	1.375 	1.5 	1.625 	1.75 	1.875
   010... 2 	2.25 	2.5 	2.75 	3 	3.25 	3.5 	3.75
   011... 4 	4.5 	5 	5.5 	6 	6.5 	7 	7.5
   100... 8 	9 	10 	11 	12 	13 	14 	15
   101... 16 	18 	20 	22 	24 	26 	28 	30
   110... 32 	36 	40 	44 	48 	52 	56 	60
   111... 64 	72 	80 	88 	96 	104 	112 	Inf 

   Задает оно значение дроби SRTT / RTTVAR. Если оно получается слишком малым
   для представления в 6 битах, т.е. передается 0, то в поле SRTT передается
   итоговое значение RTT, во всех остальных случаях SRTT.

TBD unify with Pfloat7 ?

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |ShftS|    SRTT's mantissa      | Flags |RTTVAR frac|cwnd, Ofset| 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |MSS (optional) | CCval, VarUInt32 (opt)  | Extensions (optional)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+...

TODO BOOL semi-reliable transport, BYTE it's RTT add value

TODO добавить уведомление о смене адреса, мб сам этот адрес

TODO добавить информацию о фэйле ретрансмитов мб MTU см. DTLS TBD в MTU_PROBE?

  Значение поля cwndf определяет наличие/отсутствие дополнительного байта и
  расчет cwnd. Важно отметить, что cwnd для целей декодирования этой опции
  считается в единицах MTU, которое сервер должен получить у бэкенда! Итак,
  значения cwndf:

    0 - cwnd equals 1*MTU (that is, after retransmission)
    1 - cwnd equals 2*MTU
    2 - cwnd is from 3*MTU to initial value by formula 7.2.1
    3..6 - has low-байт, it's shift is cwndf-1
    7 - присутствуют 2 low-байта, их сдвиг равен 4 - ((MSS & 0xc0) >> 6)
        для возможности лимита имплементации 32 бит в байтах

TODO для cwnd в пакетах по multipath - RFC 6356 Section 4.2
RFC 7141:
   When a transport detects that a packet has been lost or congestion
   marked, it SHOULD consider the strength of the congestion indication
   as proportionate to the size in octets (bytes) of the missing or
   marked packet.

   In other words, when a packet indicates congestion (by being lost or
   marked), it can be considered conceptually as if there is a
   congestion indication on every octet of the packet, not just one
   indication per packet.

  Например, при cwndf=3 и cwndlow=1 получаем cwnd=4 (как 1<<2) единиц MTU,
  а при cwndf=6 и cwndlow=255 получим cwnd=8160 в единицах MTU. Как можно
  убедиться, типичный размер в 1 Мб в 1-байтный формат не умещается только при
  MSS менее 64 байта (например, 6LoWPAN), в каковом случае просто пишется
  максимально возможное значение. Поскольку cwnd необходим серверу для оценки
  частоты передачи MORE_DATA, потеря точности и ограничение максимума на
  сотнях килобайт не имеют значения.

  Наконец, клиент может опционально сообщить серверу и замеренные им значения
  MSS, которые могут быть весьма отличающимися в разные стороны в силу
  асимметричности протокола. Значение кодируется одним байтом для каждой из
  сторон:

      0               
      0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+
     |Range|  Value  |
     +-+-+-+-+-+-+-+-+

  В отличие от сдвигов значений времени, где точность не очень важна, а
  перекрывающиеся значения задают с разной точностью, для MSS нет перекрытий:
  следующий диапазон начинается там, где закончился предыдущий. Иными словами,
  начало каждого диапазона равно сумме длин предыдущих диапазонов

    * 000 - 0..31 - непосредственное значение либо TBD добавление 
    * 001 - по 4 байта, диапазон 128 - 32 значения от 32 по 156
    * 010 - по 8 байт, диапазон 256 - 32 значения от 160 по 408
    * 011 - по 16 байт, диапазон 512 - 32 значения от 416 по 

    * 001 - по 1 байту, диапазон 32 - 32 значения от 32 по 63
    * 010 - по 2 байта, диапазон 64 - 32 значения от 64 по 126
    * 011 - по 4 байта, диапазон 128 - 32 значения от 128 по 252

    * 100 - по 8 байт, диапазон 256 - 32 значения от 256 по 504
    * 101 - по 16 байт, диапазон 512 - 32 значения от 512 по 1008
    * 110 - по 32 байта, диапазон 1024 - 32 значения от 1024 по 2016
    * 111 - по 64 байта, диапазон 2048 - 32 значения от 2048 по 4032

    * 100 - по 16 байт, диапазон 512 - 32 значения от 256 по 752
    * 101 - по 32 байта, диапазон 1024 - 32 значения от 768 по 1760
    * 110 - по 64 байта, диапазон 2048 - 32 значения от 1792 по 
    * 111 - по 128 байт, диапазон 4096 - 32 значения от 3840 по 7808

    * 000: 1..8 - инкремент на столько же байт
    * 000:  9 - инкремент на 16 байт
    * 000: 10 - инкремент на 32 байт
    * 000: 11 - инкремент на 64 байта
    * 000: 12 - инкремент на ?
    * 00*: 13 .. 44, по 3 байта, диапазон 93, 32 значения [33, 36 ... 126]
    * 001: 45 .. 50, по 5 байт, диапазон 30, 6 значений [130, 135 ... 155]

    * 000: 1..22 - инкремент на столько же байт
    * 0001: 23 - инкремент на 32 байт; от 28 -> 60 байт, от 24 -> 56
    * 0001: 24 - инкремент на 64 байта; от 28 -> 92 байта, от 24 -> 88
    * 00*: 25 .. 37, по 3 байта, диапазон 39, 13 значений [48, 51 ... 84]
    * 001: 38 .. 40, по 4 байта, диапазон 12, 3 значения [92, 96, 100]
    * 001: 41 .. 51, по 5 байт, диапазон 55, 11 значений [105, 115 ... 155]

    * 001: 52 .. 63, по 8 байт, диапазон 96, 12 значений [160, 168 ... 248]
    * 010 - по 8 байт, диапазон 256 - 32 значения от 256 по 504
    * 011 - по 8 байт, диапазон 256 - 32 значения от 512 по 760
    * 100 - по 16 байт, диапазон 512 - 32 значения от 768 по 1264
    * 101 - по 32 байта, диапазон 1024 - 32 значения от 1280 по 2272
    * 110 - по 64 байта, диапазон 2048 - 32 значения от 2304 по 4288
    * 111 - по 128 байт, диапазон 4096 - 32 значения от 4352 по 8320

perl -E 'for($j=0;$j<=31;$j++){printf "%4d:",$j}printf"\n";$v=256;for($i=2;$i<=7;$i++){printf"$i:";for($j=0;$j<=31;$j++){printf "%4d ",$v;$v+=2**($i+1)}printf"\n"}'

      0:   1: ... 4: ...   8: ...  12:   13: ... 16: ... 30:    31:
  2:  256  264 .  288 .   320  .   352   360 .   384 .   496    504
  3:  512  528 .  576 .   640  .   704   720 .   768 .   992   1008
  4: 1024 1056 . 1152 .  1280  .  1408  1440 .  1536 .  1984   2016
  5: 2048 2112 . 2304 .  2560  .  2816  2880 .  3072 .  3968   4032
  6: 4096 4224 . 4608 .  5120  .  5632  5760 .  6144 .  7936   8064
  7: 8192 8448 . 9216 . 10240  . 11264 11520 . 12288 . 15872  16128

TODO миним MSS=24 и без Connection Tag - 1+13 данные, 1 TSN Base, 9 COOKIE_ACK

TBD сколько, по сколько и от скольки? 8 по 32 точно один из них
128+256+512+1024+2048+4096+8192=16256 а куда столько? TBD en.wikipedia/Minifloat
TODO еще же добавление до гранулярности


4.10. MORE_DATA: Server Has Bytes Available to Request

  Одна из заметных проблем наивного протокола - низкая производительность
  в направлении от сервера к клиенту при отсутствии данных на сервер от
  клиента. Она происходит из природы протокола "запрос-ответ", когда всем
  управляет клиент, и в этом случае сервер вынужден уведомлять клиента, чтобы
  тот сделал еще запросы и забрал с сервера данные. В случае, если это решается
  одним битом, т.е. клиент на каждый пакет от сервера мог сделать только один
  запрос (и получить этот бит в нём снова, либо не получить), то есть окно
  не разгонялось более единицы, составляя передачу максимум одного пакета на
  RTT. То есть, к примеру, при пинге 50 мс и пакете 32 байта теоретический
  максимум скорости составляет 1 / 0.05 * 31 = 620 байт в секунду.

  Данная опция решает эту проблему, сообщая клиенту, сколько еще байт есть у
  сервера, позволяя клиенту создавать более чем один пакет запроса, разгоняя
  скорость (в пределах окна клиента).

  Из данных этой опции клиент поддерживает переменную mwnd, означающую,
  сколько байт ожидает доставки с сервера, и декрементирует её соответственно
  количеству подтвержденных полученных байт сервера (но не ниже нуля). Вместе
  с переменной хранится последний TSN сервера, с которым она была получена,
  для целей обновления / замены её значения.

  Опция может принимать длину 0, 1, 2 или 3 байта. В случае нуля, т.е.
  отсутствия тела, считается, что значение условно равно 16, т.е. клиент
  инкрементирует mwnd на 16 байт.

  В случае 1 байта опция имеет формат:

      0               
      0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+
     |Shift|mwndMnt16|
     +-+-+-+-+-+-+-+-+

  В случае 2 байт опция имеет формат:

      0                   1           
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Shift|    mwnd's mantissa      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  В случае 3 байт опция имеет формат:

      0                   1                   2       
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Shift|            mwnd's mantissa              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Здесь Shift - число бит, на которые нужно сдвинуть значение мантиссы, чтобы
  получить полное число, по тому же принципу, что rwnd в SACK. В случае
  однобайтного формата значение мантиссы передается уже сдвинутым, то есть
  итоговое число передается в 16-байтных единицах, давая максимальный размер
  до 64 килобайт. В двухбайтном формате - уже 1 Мегабайт, и полные 256 Мб в
  трехбайтном формате. Как и в случае с rwnd в SACK, потеря точности (округление
  вниз) на больших числах не имеет значения - сервером всё равно будет
  прислано обновленное число.

  При этом в однобайтном формате значение передается минус 1, чтобы для случая
  <=16 байт можно было слать опцию без тела (т.е. 0x01 будет значить 32 байта).

  Поскольку клиент декрементирует mwnd по мере получения новых данных, серверу
  нужно определять, когда посылать клиенту новое обновленное значение - оно, в
  случае обоих непустых форматов, заменит собой старое значение mwnd на
  клиенте. Это решается по присланному клиенту cwnd из LINK_INFO: за некоторое
  количество пакетов до его исчерпания, сервер присылает обновленное значение
  mwnd.

TBD передавать ли просьбу изменить HB.Interval ?
-> это можно сделать в ATOM_CONFIG

4.11. ERROR: Operation Error

  Используется для информирования другой стороны о какой-либо ошибке, не
  являющейся фатальной, т.е. не ведущей к разрыву соединения. Коды ошибок (и
  их формат), однако, общие с опцией ABORT, которая применяется для собственно
  аварийного разрыва ассоциации.

       0   1   2   3   4   5   6   7
     +---+-----------+---------------+
     |Res|                           |
     |erv|       Error Code          |   1 byte
     |ed |                           |
     +---+-----------+---------------+
     \                               \
     /   Error-Specific Information  /   0 or more bytes
     \                               \
     +---------------+---------------+
     |               |               |                  \
     |  Option Delta | Option Length |   1 byte          |
     |               |               |                   |
     +---------------+---------------+                   |
     \                               \                   |
     /         Option Delta          /   0-1 bytes       |
     \          (extended)           \                   |
     +-------------------------------+                   |
     \                               \                   |
     /         Option Length         /   0-1 bytes        > optional by code
     \          (extended)           \                   |
     +-------------------------------+                   |
     \                               \                   |
     /                               /                   |
     \                               \                   |
     /         Option Value          /   0 or more bytes |
     \                               \                   |
     /                               /                   |
     \                               \                  /
     +-------------------------------+

  В зависимости от кода ошибки далее могут следовать или не следовать
  специфичные для этого кода дополнительные данные. В некоторых случаях далее
  также идут скопированные данные той опции, которая вызвала ошибку. Они, если
  есть, сообщаются по принципу ICMP: гарантируется начало опции, чтобы её
  можно было однозначно распознать, и некоторое количество байт её начала.
  Отправитель ERROR в случае копии опции ДОЛЖЕН передать не менее 4 байт - для
  гарантии присутствия хотя бы 1 байта её данных (если они были), и ему
  РЕКОМЕНДУЕТСЯ включать не менее 8 байт.

FIXME здесь же не хватит дельты
TODO переделать начисто


4.18. TIMESTAMP: TimeStamp of this packet and echo of TimeStamp.

  Формат чанка с таймштампом, первый раз в соединении или через несколько
  часов, 4 байта:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Low 32 bits of Unix Time: Seconds since Mindight 01.01.1970 UTC|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Служит для компенсации возможной ошибки при дальнейшей работе, в том
  случае, если разница часов клиента и сервера очень велика (более получаса
  или даже часы).

  Формат чанка с таймштампами в обычной работе, от 3 до 9 байт:

     0                   1                   2       
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      TSval: Value of TimeStamp of sender      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     TSecr: Echo of Received TimeStamp Value   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Packet Counter for TSecr, optional: 0-3 bytes |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  В отличие от TCP, где опция 8 используется как opaque 32 bit integer, у нас
  формат времени известен, поскольку применяется для TTL блоков данных,
  и может использоваться, например, для LEDBAT (для него, впрочем, сам delay
  on the wire не передается, поскольку может быть высчитан).

  Формат времени - число с фиксированной точкой (два целых числа), где дробная
  часть - в четвертях миллисекунд, а целая представляет собой младшие
  биты стандартного Unix Time (число секунд с полночи 01.01.1970 UTC),
  в случае использования функции gettimeofday() могущие быть описаны как:

     0                   1                   2       
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    tv_sec & 0x0fff    |    tv_usec / 250      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Формат опции может быть различен по длине. В отличие от TCP, включение
  номера пакета в ответ позволяет различить, echo какого именно пакета
  содержится в TSecr, упрощая задачу точных замеров. Поле может быть пустым,
  когда сервер отвечает клиенту на эту опцию в пакете с тем же самым
  Packet Counter, или быть его младшими байтами, если старшие байты совпадают
  с Packet Counter того пакета, в котором передается опция; иными словами -
  содержатся только различающие байты после сравнения как байтовых строк.

TODO переделать - теперь часть таймштампа в Packet Id

A convenient reference is that a frequency error of 100 ppm causes an error of 8.64 seconds after 24 hours. This table presents the measurement uncertainty due to the accumulated error for longer time intervals.
Crystal oscillators that are used in personal computers and servers are typically manufactured with a frequency tolerance of ± 30 to 50 parts per million, and rarely, crystals can be off by as much as 500 ppm
Consider using two different computers to measure the same 24 hour time interval. Both computers have an oscillator with a maximum frequency offset of ± 50 ppm. How far apart can the measurement of the same time interval on these two systems be? As in the previous examples, ± 50 ppm yields a maximum error of ± 4.3 seconds after 24 hours. If one system runs 4.3 seconds fast, and the other 4.3 seconds slow, the maximum error after 24 hours could be 8.6 seconds.

Seconds in a day = 86400

Frequency offset error = ±50 ppm = ±0.00005

±(86,400 seconds * 0.00005) = ±4.3 seconds

Maximum offset between the two systems = 8.6 seconds

TBD:
можем ли мы округлить число бит вверх? а если ошибка при подстановке старших?

TSval, TSecr, Packet Counter for TSecr, Delta?

TSval:
  * либо нет
  * либо Full, т.к. в заголовке слишком короткий
  * либо встречный (S2C) в пассивном, если в заголовке нет места
    - вариант - дельта

TSecr:
  * либо нет
  * либо Full, т.к. отвечаем на чанк Full TSval
  * либо ответный на заголовок, если в заголовке нет места,
    не только в пассивном (C2S)
    - вариант - дельта

форматный байт:
  * одинаков ли для TSval и TSecr?

skew/drift:
  * передаем или вычисляем?

Packet Counter:
  * либо нет
  * либо вместе с TSecr в открытом режиме
  * либо флаг 1 битом в заголовке пассивного режима
  ? возможны ли другие варианты?

ACK Delay:
  * похоже, не зависит от наличия других полей
  ? может его вообще в SACK сунуть?

Delta:
  * может ли быть сразу два поля дельтой?
    - вряд ли
    - а если кто-то к заголовку?
  * даже одно поле дельтой - к чему? заголовок или другой штамп здесь же?
    - если считать заголовок пакета - тоже чанком TIMESTAMP, только
      сформированным туннелем, то...

  C -> S:  H=TSval_C1, PktC=C1, Delta=0, P=0
  C <- S:  H=TSecr_C1, PktC=C1, Delta=TSval_S1, P=0
  C -> S:  H=TSval_C2, PktC=C2, Delta=TSecr_S1, P=0
  C <- S:  H=TSecr_C2, PktC=C2, Delta=TSval_S2, P=0
  C <- S:  H=TSecr_C2, PktC=C2, Delta=TSval_S3, P=1
  C -> S:  H=TSval_C3, PktC=C3, Delta=TSecr_S3, P=1
  ... it was ACK, no own data, time passes, and then:
  C <- S:  H=TSval_C3, PktC=C3, Delta=TSval_S4, P=0, delay inside
     or: may be too long, so Delta=0 as invalid: TSecr(FULL)=C3 & delay inside

  struct partially_unpacked_timestamp_chunk {
      uint32                              TSval_seconds;
      uint14                              TSval_fraction;
      uint32                              TSecr_seconds;
      uint14                              TSecr_fraction;
      int30                               delta; /* Sign, 2^15 sec, 14 frac */
      uint17                              packet_counter;
      uint30                              delay; /* always in 100-microsecs */
      uint4                               bits_fraction; /* for NBITS|DELTA */
      uint5                               bits_TS_seconds;     /* for NBITS */
      uint5                               bits_Delta_seconds;  /* for DELTA */
      uint4                               bits_in_packet_counter;
      enum {NONE, NBITS, FULL, DELTA}     TSval_valid;
      enum {NONE, PBITS, NBITS, FULL, DELTA} TSecr_valid;
      enum {NONE, FOR_TSVAL, FOR_TSECR}   packet_counter_valid;
      bool                                packet_counter_extended_odd_flag;
      bool                                delay_valid;
  } virtual_timestamp_chunk_as_packet_header, real_timestamp_chunk_inside;

   TSval_valid->  NONE           NBITS      FULL       DELTA
   TSecr_valid|                                    
              v                                    
   NONE          invalid         x          x          x 
   NBITS         0, FOR_TSECR    x          x          x 
   FULL          FOR_TSECR      x          x          x 
   DELTA         FOR_TSECR    x          x          x 


   TSval   TSecr    Packet Counter     Delta    ACK Delay
   0	   0        0                  0        0
   0	   0        0                  0        0

если для UDP 11+10=21 бит, для обоих 42 бита

2  - 1/4 = 250 ms
3  - 1/8 = 125 ms
4  - tv_usec / 16 = 62500 us
5  - tv_usec / 32 = 31250 us  # не годится в 100 мкс 
6  - tv_usec / 64 = 15625 us  # не годится в 2 мкс и 10 мкс
7  - 1/125 = 8 ms
8  - 1/250 = 4 ms
9  - 1/500 = 2 ms
10 - 1 ms
11 - 1/2000 = 500 us
12 - tv_usec / 250 = 250 us   # не годится в 100 мкс 
13 - tv_usec / 500 = 125 us   # не годится в 2 мкс и 10 мкс
14 ? вариант: 100 мкс
15 - variant: tv_usec / 25000 = 40 us
16 - variant: tv_usec / 50000 = 20 us
17 - tv_usec / 100000 = 10 us
18 - variant: tv_usec / 250000 = 4 us
19 - variant: tv_usec / 500000 = 2 us
20 - 1 us

TODO other multipliers for 14-17

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |TVv|TEpcval|P|D|      Delay, VarUInt32, if D ...               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |TSsecLen*|DsecL|FraL*|PktCLen**|TSval Seconds..* |TSval Frac..*|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | TSecr Secs...*  | TSecr Fractional...*  |S| Delta Seconds...* |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Delta Fractional...*   |  Packet Counter...*   |Pad to byte|
    +-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+-+-+-+-+

   */** marked fields are optional and/or variable length - after the first
   byte and possible Delay field the rest is concatenated bitstrings

   TVv - TSval_valid:
     0 - NONE,
     1 - NBITS, 
     2 - DELTA
     3 - FULL
   TEpcval = TSecr_valid * 3 + packet_counter_valid:
     TEpcval / 3 = TSecr_valid:
       0 - NONE,
       1 - PBITS, 
       2 - NBITS, 
       3 - DELTA
       4 - FULL
     TEpcval % 3 = packet_counter_valid:
       0 - NONE,
       1 - FOR_TSVAL 
       2 - FOR_TSECR
   P - packet_counter_extended_odd_flag
   D - delay_valid

  TSsecLen - number of bits in seconds part, if any is NBITS
  DsecL - number of bits in seconds part, if any is DELTA
    TBD 0..7, so how many to add?
  FraL - number of bits in fractional part of NBITS & DELTA, by table:
    TODO see above where 1/8

  PktCLen - number of bits in Packet Counter field, itself of variable len:
  single bit 1    - means "take width from Previous / Packet Header"
  or 5 bits 0xxxx - means 4+value in four bits xxxx -> 19 max
    TBD why 4..19 good? I've forgot rationale :(
      TBD may be coz it's 20 bit when with odd flag?

  S - is sign bit of Delta

Example 1: for UDP size M, header has 11 bits of tv_sec, 10 bits for
  Milliseconds and 9 bit Packet Counter. To answer it, TSecr_valid=PBITS and
  packet_counter_valid=FOR_TSECR, thus first byte, 1 bit for PktCLen, and then
  values: 11 bits, 10 bits, 9 bits, 31 bit total, 1 bit padding, 5 bytes
  total.
  TODO draw figure

Example 2: for ICMP, header has 11 bits of tv_sec, 10 bits for
  Milliseconds and 16 bit Packet Counter, also a Delta with 1 bit for Sign
  and 6 bits for seconds part with same 10 for Milliseconds;
  and finally P bit for packet_counter_extended_odd_flag.

  TODO what? it's all in header TBD may be if Delta=0 thus invalid?


TBD бит для того, что не настоящий штамп, а DUP с прошлой сессии?
TBD или в STREAM_CONTROL его?
TBD для DUP можно в DATA выделить байт или VarInt16, от базового stamp
но тогда гранулярность времени поменьше бы
TBD а может, таки миллисекунды? и Delay 1-3 байта (0,10,11) до 22 бит?
-> DUP is now in CBAR, ignore it here

TBD case for Packet Counter + Delta from client - this is, in fact, TWO packet
counters in header of such packet! one real, and one TSecr by Delta for
counter -2+P, but only if Delta is valid; and for server P is independent from
validness of Delta

every packet, before serialization or after decoding, has variables:

   struct timeval *TSval   = NULL;
   struct timeval *TSecr   = NULL;
   uint precision_bits_val = 2;    /* like /16 in CIDR */
   uint precision_bits_ecr = 2;    /* like /16 in CIDR */
   uint *PacketCounter_val = NULL; 
   uint *PacketCounter_ecr = NULL; 

and then header and and possibly TIMESTAMP option initializes or even
overwrites some or all of them.

...so, for Baseline-Time variant, possible cases:

0) TSval only, not PacketCounter (option, used to precisify value in short header)
1) TSval only and it's PacketCounter (usual header e.g. in UDP)
2) TSecr only, PacketCounter is for TSecr, P/Odd=0 (header, gray mode, from server)
3) TSecr only, PacketCounter is for TSecr, P/Odd=1 (header, gray mode, from server)
4) TSval + TSecr, PacketCounter is for TSval only (header, gray mode, from client, Delta invalid)
5) TSval + TSecr, PacketCounter is for TSval and for TSecr, PacketCounter_ecr:=PacketCounter-2+P;
6) same, for P/odd=1

delay may be valid only when has TSecr, so put another five combinations?

cases 0 and 1 may be in short format? e.g. 3 high bytes of tv_sec, then 1 byte
if granularity 2-3 bits (PacketCounter is not possible - very short)
-> 4 byte format = 3 high bits of tv_sec + low 8 bits of Milliseconds (8.2 in hdr already)

TBD just AND / shift - so performance? as Septinovile is usually for long ops anyway

TBD use VarNibbles for non-full variants instead of bits complexitites
- 18.08.25 or may be Golomb or Elias delta/gamma coding?

TBD what about P on XS packets? on S size it possible just have another
PacketCounter from server - reduced MSS in this direction, but XS may have no
space left due to Nonce

TBD

4.19. ECNE_CWR: TODO

назначение CWR - прекратить отсылку ECNE (типа ack), т.к. мог быть дроп
TBD так что репортить его в этой опции или в LINK_INFO ?
- в обеих?

   On the other hand, if
   the TCP data receiver honors the CE indication in the out-of-window
   packet, and reports the indication of congestion to the TCP data
   sender, then the malicious node that created the spoofed, out-of-
   window packet has successfully "attacked" the TCP connection by
   forcing the data sender to unnecessarily reduce (halve) its
   congestion window.  To prevent such a denial-of-service attack, we
   specify that a legitimate TCP data sender MUST NOT set an ECT
   codepoint on retransmitted data packets, and that the TCP data
   receiver SHOULD ignore the CE codepoint on out-of-window packets.

   Therefore, the TCP data sender MUST NOT set either an ECT codepoint
   or the CWR bit on window probe packets.

   +--------+--------+--------+--------+--------+--------
   |0010011?| Length |SSLLLLLL|SSLLLLLL|SSLLLLLL|  ...
   +--------+--------+--------+--------+--------+--------
   Type=38/39         \___________ Vector ___________...

   The two Ack Vector options (option types 38 and 39) differ only in
   the values they imply for ECN Nonce Echo.  Section 12.2 describes
   this further.

   The vector itself consists of a series of bytes, each of whose
   encoding is:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |Sta| Run Length|
   +-+-+-+-+-+-+-+-+

   Sta[te] occupies the most significant two bits of each byte and can
   have one of four values, as follows:

                    State  Meaning
                    -----  -------
                      0    Received
                      1    Received ECN Marked
                      2    Received Duplicate
                      3    Not Yet Received

TODO использовать дупы по алгоритму из RFC 3708
TBD ECN nonce sum proposal по [RFC3540] и по DCCP
  CWR |ECNonceSum| ECT(0) Count in Last 7 | ECT(1) Count in Last 7 Pkts |
TODO в QUIC делают проверку на дропы с ECT(0) от плохих роутеров (13.4.2)
в первый раз отправлять не ранее чем после 7 нормальных (не INIT) пакетов
TBD изменить формат, раз на диоде формат нечетных дополнительного бита,
и сменить LLLLL на Pyramint5
-> no need if no P bit: just force XS to black mode?

      +-----+-----+
      | ECN FIELD |
      +-----+-----+
        ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
         0     0         Not-ECT
         0     1         ECT(1)
         1     0         ECT(0)
         1     1         CE

  0 - Received Not-ECT
  1 - Received ECT(1)
  2 - Received ECT(0)
  3 - Received ECN Marked (CE)
  4 - Received Duplicate, both Not-ECT
  5 - Received Duplicate, one ECT(1), one or more Not-ECT
  6 - Received Duplicate, one ECT(0), one or more Not-ECT
  7 - Received Duplicate, one ECN Marked (CE), one or more Not-ECT
  8 - Received Duplicate, 3 or more Not-ECT
  9 - Received Duplicate, 2 or more ECT(1), one or more Not-ECT
  10 - Received Duplicate, 2 or more ECT(0), one or more Not-ECT
  11 - Received Duplicate, 2+ ECN Marked (CE), 0+ Not-ECT
  12 - Not Yet Received
  13 - Not Received, but recovered by FEC
  14 - We under attack - duplicates with different ECN codepoints
       TBD 26.08.25 is not a 100% indicator of attack
  15 - Reserved TBD or "AUTH failed" ? or report HMAC fail in ERROR opt?

TBD or: just a count (0-3) for each codepoint? but how FEC then?
if 0/1/2=2 or more, then 3^4=81, 81*3=243 and 13 reserved values!

TBD drop codes 8-11 for extension - time/PacketCounter, instead of PkCntWrap?
- how to encode both values under 30 bits? or extend TIMESTAMP reply with next
  time/PacketCounter pair?
- 26.08.25 DCCP Section 11.7 also have Drop Codes, incorporate them too

TBD 26.10.24 ~6:00 moving average histogram of packet sizes on receiver - to
report to sender for MTU change detection/recovery

TBD 06.11.24 https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/30/ :
<< *  an essential part that re-uses the TCP-ECN header bits for the
      Data Receiver to feed back the number of packets arriving with CE
      in the IP-ECN field.  This provides more accuracy than Classic ECN
      feedback, but limited resilience against ACK loss;
   *  a supplementary part using one of two new alternative AccECN TCP
      Options that provide additional feedback on the number of bytes
      that arrive marked with each of the three ECN codepoints in the
      IP-ECN field (not just CE marks).  This provides greater
      resilience against ACK loss than the essential feedback, but it is
      currently more likely to suffer from middlebox interference.
>>
TBD 07.11.24 ~02:15 use CoAP options format: first nibble may have extended packet
info from IPnh, other for run length
RFC 3124 (Congestion Manager) - ownd, stream scheduler //move to QoS stream?

-- 02.12.24 CoAp option-like format:

     0   1   2   3   4   5   6   7
   +---------------+---------------+
   |               |               |
   |  Packet State |  Run Length   |   1 byte
   |               |               |
   +---------------+---------------+
   \                               \
   /     Packet State Length       /   0-2 bytes
   \          (extended)           \
   +-------------------------------+
   \                               \
   /          Run Length           /   0-2 bytes
   \          (extended)           \
   +-------------------------------+
   \                               \
   /                               /
   \                               \
   /      Packet State Value       /   0 or more bytes
   \                               \
   /                               /
   \                               \
   +-------------------------------+

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+...
     |DupCn|Value Len| Something seriously wrong with this idea (!B) not continue
     +-+-+-+-+-+-+-+-+...
--/02.12.24

TBD 26.08.25 as "latest -> down" not necessary (see this day why DCCP had it),
possible to do variable-based: e.g. +1 to timestamp, +1 to PktC, := to state,
and Run Length e.g. could just repeat "counter++, state=..."; also think about
sync - e.g. option to request Packet Vector from id N ?
- reminds DWARF LNS, and it can become extensible to Packet Matrix, not just
  Packet Vector here! Some initial setup and then VarNibbles for columns?


4.20. FRAGMENT.

  Используется в тех случаях, когда после изменения пути, например, отказе
  одного из адресов, MTU оставшихся (или нового) стал меньше (возможно,
  вплоть до минимума в 24), в то время, как данные уже распределены по
  TSN-чанкам, а изменять их нельзя. Чтобы иметь возможность продолжения
  работы в таких условиях, и не повторять код в бэкендах, такие длинные чанки
  могут быть доставлены короткими фрагментами - в чем-то повторяя принцип
  доставки самих больших блоков, состоящих из многих чанков.

  Общий формат чанка:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Transmission Sequence Number, serving as a fragment ID     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Type/FragNumber| Type-specific Data... 
    +-+-+-+-+-+-+-+-+-+-+-+-....

  К передаче фрагментов применяются те же принципы (позволяя использовать тот
  же код), что и к передаче самих TSN - условные "флаги" Begin, End, номер
  фрагмента, являющийся аналогом Fragment Sequence Number, и аналог SACK.
  Кодируются, однако, все они другим способом.

  В качестве идентификатора всех фрагментов выступает полный TSN исходного
  чанка. Он мог бы передаваться (кроме ACK) вне собственно чанка FRAGMENT, что
  позволило бы в некоторых случаях сэкономить один байт на заголовке (при длине
  меньше или равной 15 байт), однако тогда возникла бы проблема передачи новых,
  нефрагментированных, чанков, одновременно с фрагментами старых - в случаях,
  если MTU упал не до минимальных значений, а на какую-то разумную величину
  в типичных обстоятельствах (скажем, трафик пошел по VPN). Экономия одного
  байта не стоит долгой блокировки всех потоков (вместо лишь части) лимитом
  в 32 номера от самого старого фрагмента, если в очереди их было больше.
  К тому же это позволяет использовать тот же фрагмент кода для HMAC по TSN.

TODO если чанк был нефрагментированный, а HMAC нужен, и был бы в пакете, то
точно также будет и для BE=11 - длина позволяет отличить, когда он начнется,
просто вместо Update() для вероятного следующего сразу Final()

  Далее, используя то соображение, что при фрагментации имеет смысл делать
  фргаменты по возможности больше, итоговое число фрагментов ограничено,
  поэтому пространство номеров может быть поделена неравномерно.

  Передача первого фрагмента:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Transmission Sequence Number, serving as a fragment ID     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1 1|.. Orig. Chunk Length|S|B|E| Chunk Number  | Chunk Data... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....

-- variant 2

если TSN Base 28 бит, то схема первых бит сохраняется: в TSN биты SBE
и формата Internal/User, для User точно так же префикс длины 0b10 максимум,
и 3 бита номера (на месте SBE рисунка выше); для Internal сначала 5 бит номера
и потом 9 длины, причем так как 0b1111, то номера 0..23
TBD а шо делать с FSBE в не-первых фрагментах?
можно по аналогии с BE биты First/Last, и FL=11 будет Ack, 1 бит для
компрессии (на 1 байт меньше) если фрагментов мало

variant 2.1 если TSN Base 29 бит, то
1+S+B+E+I+(len+number=14) для первого
00+L+8 бит FSN для второго/далее,
01+S+8 бит FSN для ACK - бит S типа SACK битмап через следующий

или наоборот, два бита на SACK и уменьшить len+number=13 что даст возможность
объединить дельты i/u и высвободить 8 кодов опций

TBD что делать с FORWARD_TSN ? в этом формате для I только 512 длина же
TODO запрет на размер E-чанков больше min MTU при AUTH, чтобы не возиться
с HMAC здесь, во фрагментах

variant 2.2: если TSN Base 29 бит, то
0+S+B+E+I+(number+len=14) для первого
1+десять бит смещения в единицах 2 байт - для второго и далее
1+0000000000+десять бит смещения - ACK, дальше 3 бита estimate gap 2^(N+1) и
тоже 3 бита estimate bytes after gap, в том же формате, оба rounded down

TODO короткий вариант ACK - 3 байта, 19 бит Packet Counter и 5 бит следующих

-- /variant 2

 Поскольку в нормальном состоянии первый байт чанка кодирует дельту
 относительно базового TSN пакета, здесь его передавать не нужно, кроме трех
 его флагов - зато нужно передать полный номер чанка, без дельта-кодирований.

 Следует обратить внимание, что длина, хотя на неё и отведено 11 бит,
 допустима только до 1535 - дальнейшие значения будут означать ACK, см. ниже.

 Передача второго и далее фрагментов:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Transmission Sequence Number, serving as a fragment ID     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Last+FragNumber| Chunk Fragment Data, >=16 b. if O.Len>1440... 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....

  Первый байт кодирует номер фрагмента и флаг того, что это последний
  фрагмент, следующим образом: значения от 0 по 191 поделены на две половины,
  и значения 0-95 означают "промежуточный" номер фрагмента, а 96-191 дают
  "последний" фрагмент, номер которого получается вычитанием 96. Отсюда
  вытекает лимит на максимальное число фрагментов, и следствие, что при длинах
  оригинального чанка около полутора килобайт - минимальный размер каждого
  фрагмента ДОЛЖЕН быть не менее 16 байт (он может быть, соответственно,
  меньше - при меньшей исходной длине).

TBD откуда считаем 0-й оффсет? если не с реального нуля, то что в ACK ?
что делать, если окно закрыто?
TBD добавить 97-й? исходя из того, что максимальный номер can't be non-last

 Подтверждение полученных фрагментов твой стороны - аналог SACK - имеет
 несколько вариантов формата, в зависимости от длины, давая оптимизацию для
 более типичных (коротких) случаев:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Transmission Sequence Number of your side fragments      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1 1 1 1|FragAck|
    +-+-+-+-+-+-+-+-+

TBD bitmap? или SACK 1 и лимит не более 16 или 32 фрагментов in flight?

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Transmission Sequence Number of your side fragments      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1 1 1 1|Cuml.Frag.Ack| Bitmap  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  В случае короткого и/или без пропусков применяется 5-байтный формат,
  в противном случае - 6-байтный. Значения полей аналогичны SACK, только
  в качестве Cumulative Ack выступает номер фрагмента, а не TSN; собственно
  идентификатором фрагмента (на что отвечаем) выступает TSN, использовавшийся
  с той стороны.

  Таким образом, в пакете с TSN Base ДОЛЖЕН быть только один чанк FRAGMENT,
  у которого первый байт имеет значение менее 0xf0, и этот FRAGMENT задает
  фрагмент оригинального чанка с номером TSN Base пакета. Остальные чанки
  FRAGMENT в пакете, если присутствуют, могут быть только типа ACK на чанки
  FRAGMENT другой стороны, имея первый байт в диапазоне 0xf0..0xff.

  Rationale: применение данной схемы, вместо традиционного разбиения на
  кратные блоки и передачи смещения фрагмента, позволяет оптимально заполнять
  пространство пакета на минимальных MTU и экономить байты. Предположим, что
  для полной длины в 1535 байт при 7 битах на смещение потребовалось бы делить
  на блоки, кратные 12 байт (кроме последнего), или кратные 6 байт в случае
  смещения размером 8 бит - оба варианта при MSS=24 плохо заполняют место при
  необходимости присутствия FRAGMENT ACK для встречной стороны (если MTU упал
  в обе стороны), или возникает необходимость применения дополнительных
  номеров чанков, или и вовсе не влезает самый первый фрагмент вместе с полным
  TSN Base (18+3+2+4=27 байт).

-- variant Packet

  There is a bunch of problems with TSN-based fragmenting. First of all,
  retransmitted fragment will have another timestamp, so format must be
  complicated. Second, when having HMAC, there is problem with E-chunks - need
  two lengths now. Moreover, if there are several BE-chunks in one packet,
  there will be overhead for each, and if there was only one AUTH chunk for
  such packet, overhead will be even worse. So, for simplicity of
  implementation, fragmentation is for entire packet - after reassembly it is
  just fed into generic packet parser, pretending it was just too long
  traveling in the network.

  For this, a separate "stream" with it's SSN is defined (outside of any
  normal TSN streams), every message in which is one packet, fragmented as
  usual messages to B/E-chunks would be, but with byte numbering and byte
  offsets instead of FSN - this allows to refragment the same data to
  different size packets while searching for proper MTU.

  Generic option format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FLA| Frag Strm SeqNum|  H/len  |   Offset/Length, 1/2 bytes    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Data...
    +-+-+-+-+...

    Here FLA is type of fragment, First/Last/Ack:

     0 - first fragment, with header
     1 - middle fragment
     2 - last fragment
     3 - SACK: fields are for opposite direction

   First fragment contains packet header:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 0 | Frag Strm SeqNum|TSL|TimeL| Packet body Length, 1/2 bytes |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Path ID, 1/2 bytes        | Header Timestamp, variable    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  length, TimeL+5 bytes ...    | Packet body data   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

    Here, Header Timestamp is contents of TIMESTAMP option corresponding to
    header of original packet, always with FULL TSval (so it's length can't
    be less than 5 bytes), parsed with the same code as TIMESTAMP option
    into virtual_timestamp_chunk_as_packet_header, and TSL describes first
    bytes of packet body data.

TBD how many bytes MUST in first frag? allow Timestamp split?
-> if Hash is by entire Timestamp, then NO

    Note that packets containing FRAGMENTS options MUST NOT be fragmented
    again.

   Middle and last fragments:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FLA| Frag Strm SeqNum|Hash sum |  Offset, 1/2 bytes            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Data...
    +-+-+-+-+...

   And ACK has it's Fragment Stream Sequence Number and Hash Sum fields
   from opposite direction's fragment, to which this ACK is reply:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 3 | Frag Strm SeqNum|Hash sum |Cumulative Received, 1/2 bytes |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | SACK data as Bitmap ranges, optional, cutted on any byte
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   For SACK ranges interpretation is as in SACK option, but in bytes,
   not in packets.

   Hash Sum in second and subsequent fragments is value calculated from
   Timestamp (in first fragments) which is used as additional fragment
   identificator to Sequence Number - to reduce probability of old stale
   fragments corrupting new fragments when cwnd is still large.

TODO hash function itself
TBD it's better to just widen FSSN, but where to put TSL/TimestampLen then?
more simple implementation requires using same parser of TIMESTAMP, not new
packing format

TBD speed requirements? be Hash just bits 9-13, or whatever width is,
containing packet's Timestamp?

TBD if put full TIMESTAMP in every fragment, then SSN is not needed

TBD full TIMESTAMP option is too complex? but need this if header had Delta, too
...or not? Delta is to tightly encode both TSval and TSecr, it probably will
be stale at the time of fragmenting, so full TSval, TSecr and P/odd better

TBD may be simplify TIMESTAMP itself? also has this problem for DUP, btw
-> for DUP it is solved by CBAR non-NULL time_t and
  "just add this uint32 to shifted frac" in regular and DUP

TODO PkCntWrap

-- /variant Packet

-- variant Packet 2

as in Packet, but first TSN of packet is used as Fragment ID, length is
limited to 16 Kb, and VarNibbles for header:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Transmission Sequence Number, serving as a fragment ID     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FLA|Packet Length/Offset/C. ACK| Data...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Middle and last fragments:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Transmission Sequence Number, serving as a fragment ID     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FLA|         Offset            | Data...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   First fragment contains packet header:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Transmission Sequence Number, serving as a fragment ID     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 0 |      Packet Length        | Packet Header, in VarNibbles, |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+
    |  see description...           | Packet body data
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Packet Header data in VarNibbles array:

     Client Address No,
     Server Address No,
     tv_sec delta from start of connection, //TBD
     tv_usec << 2 + TSL,
     Packet Counter.

-- variant Packet 2.1: not packet, just TSN container, so AUTH key and hash (if has BE), no TSL/addrs/counter

   And ACK has TSN of opposite direction:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Transmission Sequence Number of your side fragments      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1 1| Cumulative Offset ACK     | SACK as Bitmap ranges
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

TBD what to do if same TSN was retransmitted on two or more different paths,
which packet to select for fragmentation?

TBD if chunks returned to options and TSN again per chunk, then need
Chunk Type and ABES... may be HMAC length if BE=11 ?

-- /variant Packet 2

-- variant Packet 3

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |FLA|Packet Length/Offset/ACK |Time 8-4 | Frag Stream Seq Number|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Data...
     +-+-+-+-+...

   Time 8-4 is low bits of tv_sec except four lowest bits, that is, it
   MUST be same as bits 23-27 of tv_sec on diagram for Virtual Packet.
   This is intended to be like Timestamp option in TCP to filter too old
   fragments with the same Sequence Number.

TBD do we need it? each fragment will have time of outer packet

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0|      Packet Length      |Time 8-4 | Frag Stream Seq Number|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Data...
     +-+-+-+-+...

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1|  Cumulative Offset ACK  | Time 8-4 and FSSN of your side  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | SACK as Bitmap ranges, optional
     +-+-+-+-+...

   Reassembled packet has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     tv_sec, full 32 bits                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Shared Key ID     |           tv_usec, 20 bits            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Base Transmission Sequence Number               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Virtual Packet Data, with usual options format...
     +-+-+-+-+...

   The Virtual Packet MUST NOT include any options or their variants which
   could trigger any packet-level response, or be such response, e.g.
   TIMESTAMP option of full packet timestamp or reply (Packet Counter),
   having Packet State (ECN) Vector, etc. - because it does not belong to any
   real "physical" link. Essentially that means that only options like DATA
   chunks, AUTH options and redefining TIMESTAMP's for B-chunks are allowed,
   and some others (like MORE_DATA).

   Shared Key ID is taken from the same space as for A=1 TSN chunks, that is,
   for "NULL" server address.

   Fragment sender MUST NOT send more bytes for all in-flight fragments than
   size of receiver's advertised Fragment Reassembly Buffer, which, in turn,
   MUST be bigger by about 1/16 of maximum supported MSS (to have space for
   timestamps and authentication options), e.g. 4380 for 4096 byte MSS.
   To simplify implementation, there is no "window update", receiver buffer is
   freed only by size of fully transfered fragment. For example, for
   receiver's buffer 6 Kb in size sender can have three 2 Kb size fragments
   in-flight, and transmission of fourth may be started only when one of these
   three is fully acknowledged, freeing 2 Kb at once.

TBD 4380 too much? is 1500 enough for standard 1440 MSS ?

-- /variant Packet 3

-- variant TSN: 111xxxxx for fragments in TSN Layer? again AUTH problem for BE=11

-- variant recursive: Chunk Type Fragment, packet in message, SACK them all!

-- variant Packet Counter to decrease Id/offset size?

+ no separate Ack, just common Packet State vector
+ no byte count logic, use "prev counter" for tree of descendants when probing MTU
- no path independence...

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|    Virtual Packet Length    |     tv_sec delta, int16       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Shared Key ID     |           tv_usec, 20 bits            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Base Transmission Sequence Number               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Virtual Packet Data, with usual options format...
     +-+-+-+-+...

middle/last fragments:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|L|PktCntrOffs| Fragment of Virtual Packet Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

TBD Last+FragNumber to increase offset to 96 ? then minimal Packet Counter width question...
- L could be just right bit to not divide 192 by 2

   When chain of fragments is successfully traversed from last to first,
   receivers frees all buffered FRAGMENT options of packets with Packet
   Counter from first to last.

TBD what if last succesfull was not last try, how to free those after last?

-> each frag must be extended with pointer to first frag so it's known which
   chain it belongs to
   - this must not be sum, as e.g. 256+1 and +96 just leaves space for
     interleaving without real possibility to put e.g. 256+30 between them

middle/last fragments:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |PktCntrOffset|L|FirstPktCntrOfs| Fragment of Chunk Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

first fragment:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 0 0|      Chunk Length     |ChuType|A|B|E|S|ShKeyID|HMACLen|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      tv_sec Delta     |           tv_usec, 20 bits            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Transmission Sequence Number                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Chunk Data, after first byte...
     +-+-+-+-+...

HMACLen:

 0 - no HMAC
 1 - 4 bytes
 2 - 6 bytes
 3 - 8 bytes
 4 - 10 bytes
 5 - 12 bytes
 6 - 14 bytes
 7 - 16 bytes
 8 - 20 bytes
 9 - 24 bytes
10 - 28 bytes
11 - 32 bytes
12 - 40 bytes
13 - 48 bytes
14 - 56 bytes
15 - 64 bytes

drop fragment buffers (Sender-Abort):

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 0 1|Reservd| Array of bytes, each is PktCntrOffset to drop
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

receiver error:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 0|ErrCode|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD only TSN or unknown frags also? 
- may be just use TIMESTAMP reply for this? TBD bitmap/array for more pkts to
  report?


RFC 8724:
   SCHC ACK REQ:  A request by the sender for a SCHC ACK from the
      receiver.

   SCHC Sender-Abort:  A message by the sender telling the receiver that
      it has aborted the transmission of a fragmented SCHC Packet.

   SCHC Receiver-Abort:  A message by the receiver to tell the sender to
      abort the transmission of a fragmented SCHC Packet.

   The RCS MUST be computed on the full SCHC Packet concatenated with
   the padding bits, if any, of the SCHC Fragment carrying the last
   tile.  The rationale is that the SCHC reassembler has no way of
   knowing the boundary between the last tile and the padding bits.
   Indeed, this requires decompressing the SCHC Packet, which is out of
   the scope of the SCHC reassembler.

TBD if ack is lost, then SCHC has ACK-REQ by sender's timeout

-- /variant Packet Counter

-- variant Packet 09.11.24 (see also this day): combine variants Packet 2.1
and packet 3 with err-codes from variant Packet Counter, but with no separate
packet headers as this is virtual packet - just TSN base as fragment ID and
Shared Key ID for AUTH - everything else is done by options 0-4 (only these
allowed) like in usual packet, and virtual packet is built like a usual
packet, just with extra TIMESTAMP/AUTH/etc. options (DUP info), as it would be
with usual physical retransmission packet on a link with bigger MTU...

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Base Transmission Sequence Number, serving as a fragment ID  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FLAEC|PacketLen/Offset/CumulACK| Data...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   0 - first, Shared Key ID Len = 1 byte
   1 - first, Shared Key ID Len = 2 bytes
   2 - first, Shared Key ID Len = 3 bytes
   3 - middle
   4 - last
   5 - sender error code
   6 - receiver: ack
   7 - receiver: error code

TODO errcodes, copy paragraph about advertised Fragment Reassembly Buffer etc.

-- /variant Packet 09.11.24

4. NAK

for stream where window is less than chunk size but relatively big there is
ambiguity - so implementation MAY send NAK but also MAY accept it, for case
sender is opportunistically sent chunk in hope window will increase while
in flight TBD also SWS (silly-window syndrome)

4.
TODO

5. Internal streams.

SipHash for 64 bit and HalfSipHash for 32 bit
- and/or UMAC from OpenSSH

   Consider an example of censorship system disallowing any long-lived
   HTTPS connections

время жизни ключа: 1 байт, 3 бита Shift, до 31 дня в единицах 675 секунд, 0=2MSL


for very short packets, where 8-byte blocks needed, in addtition to GOST, the
following crypto can be used: take a SipHash by negotiated key of fixed
strings "A", "B", "C", ... and XOR it's outputs with plaintext - effectively
a short stream cipher, however, NOT RECOMMENDED as it is not studied
-> no, stream ciphers require HMAC or bytes could be blindly modified, only CBC may be here

5.1. AUTH option

TODO move to section 4, 

      0                   1                   2       
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....
     |Algorithm|Param|KeyLo|BefoLen|Length in Padding| MAC value
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....

    * Algorith - TODO
    * Param - параметры выбранного алгоритма, если есть
    * KeyLo - если равен 0, взять из пакета, иначе номер ключа
    * BeforeLen - насколько сдвинуть левую границу, если не первая опция
    * Length in Padding - сколько байт после терминирующего 0xFF, max шаг MTU

   В подготовленном пакете, где отведено место под AUTH, на её место, включая
   сам байт длины опции, делается memmove() в её конец не более её длины из
   данных начала пакета от после Connection Tag, или даже и его часть, если
   перед ней слишком коротко TBD от -4 байт TBD

    0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---...
    | ConnectionTag |1 C|AlgParKeLen|        MAC Value              |OtherOpt
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---...


    0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---...
    | ConnectionTag |TSNBase|0 4|Cumulative TSN |1 4|AlgParKeLen| 0 |OtherOpt
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---...

->

    0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---...
    | ConnectionTag |TSNBase|0 4|Cumulative TSN |tionTag|TSNBase|0 4|OtherOpt
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---...
                                |<----...

  а если

        3   4   5   6   7   8   9   10  11  12  13  14  15  16  17  18
    ...-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---...
    ctionTag| Full TSN Base |0 7|Cumulative TSN |a_rwnd |SACK 0 |1 7|AlgPar..
    ...-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---...

  то

        10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25
    ...-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...
      umulative TSN |a_rwnd |SACK 0 |1 7|AlgParKeLen|       0       |OtherOpts
    ...-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...

  станет

        10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25
    ...-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...
      umulative TSN |a_rwnd |SACK 0 | Full TSN Base |0 7|Cumulative |OtherOpts 
    ...-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+...
                    |<---...

   т.е. один байт Cumulative TSN Ack остался непокрытым. Для решения этой
   проблемы и существует BeforeLen, который в данном случае достаточно сделать
   равным 1, 


TODO

   Suppose бэкенд дает нам MTU 100 байт, фрагментируя в 4 пакета по 33 байта,
   где 24 байта шифрованных данных, 4 байта SrvNum/Packet Stamp/Counter, 1 байт
   о номере фрагмента и еще по 4 байта, в которых сначала передаются 4 байта
   Connection Tag, 1 байт Shared Key ID и еще остается 11 байт Nonce.
   Тогда включение что MAC по 4 байта в каждый пакет (SipHash32), что режим
   типа CCM - привели бы к снижению с 96 байт до 80 полезных. Тогда как опция
   AUTH, одна на все 4 фрагмента дала бы оверхед только 12 байт на SipHash64.

XXX сколько реально? определить формат
XXX если 5 фрагментов в 4 битах (Фибоначчи) + Packet Counter = 3 байта из 33,
то можно MTU 128 в AES + еще 4 на tag, а для INIT так и все 143

TBD а может бит формата, и альтернативный вариант - AUTH по диапазону TSN?
тогда бандлить её всегда с TSN, иметь 4 бита - Start, Update, Final, формат
Update - Bitmap как в SACK

TODO

5.2. Messages on crypto stream.

   There
TODO supported variants:
* direct request of new key from server (when over already encrypted)
* EAP support
* KEX from SSH
  - 0..239 for 0..79 in 3 variants: direct, proxy, double proxy
* public key for Key 1, that is, for INIT, in addition to pre-shared symmetric

5.2.1. CRYPTO_DIRECT_KEY and CRYPTO_DIRECT_KEY_REPLY.

   Directly set bytes of key material. This method is intended for very
   constrained clients and MUST NOT be used over unencrypted channel - in
   particular, it SHOULD NOT be used in packets with Shared Key ID 0, unless
   it is known from some externally configured by administrator source that
   encryption in present on such packets (e.g. by encryption of 6LoWPAN).

   Here are two messages - client request with parameters and beginning of key
   material and server reply (if not error) with continuation of key material.

   Client CRYPTO_DIRECT_KEY format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Key Lifetime  | Key Length|P|T|    Key ID     |Algorithm|Param|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                   Beginning of Key Material                   /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * P is "permuted" flag - that client's bytes should go after server bytes
   * T is type of Key ID:
     0 - packet encryption key, for Shared Key ID field
     1 - HMAC key, for use in AUTH chunks and ends of TSN chunks

   Server CRYPTO_DIRECT_KEY_REPLY format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Algorithm|Param|                                               |
     +-+-+-+-+-+-+-+-+                                               \
     /                     Ending of Key Material                    /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If everything is OK, server installs key into tunnel backend and then
   replies to client, so that packet exchange using new key can continue
   immediately from the next client's packet. Server may start using new key
   in it's packets when TSN chunk with reply is acknowledged by client.

TBD key len/id/algo select may be VarNibbles? algo/param must be for both
crypto and MAC or nothing; also they duplicates with AUTH option

TODO

TODO

=== quotes from other protocols ===

RFC 5723:
   To avoid this issue for "ticket by value", an Invalid Ticket List
   (ITL) may be maintained by the gateway, see [TOKENS].  This can be a
   simple blacklist of revoked tickets.  Alternatively, [TOKENS]
   suggests to use Bloom Filters [Bloom70] to maintain the list in
   constant space.  Management of such lists is outside the scope of the
   current document.  Note that a policy that requires tickets to have
   shorter lifetimes (e.g., 1 hour) significantly mitigates this issue.

   [Bloom70]     Bloom, B., "Space/time trade-offs in hash coding with
                 allowable errors", Comm. ACM 13(7):422-6, July 1970.

   [TOKENS]      Rescorla, E., "How to Implement Secure (Mostly)
                 Stateless Tokens", Work in Progress, March 2007.

DCCP:
   
wide, where W is the value of the Sequence Window/B feature.  One-
   fourth of the sequence window, rounded down, is less than or equal to
   GSR, and three-fourths is greater than GSR.  (This asymmetric
   placement assumes that bursts of loss are more common in the network
   than significant reorderings.)
One good
   guideline is for each endpoint to set Sequence Window to about five
   times the maximum number of packets it expects to send in a round-
   trip time.

connection is considered active if it has received valid packets from
   the other endpoint within the last three round-trip times.

To protect against denial-of-service attacks, DCCP implementations
   SHOULD impose a rate limit on DCCP-Syncs sent in response to
   sequence-invalid packets, such as not more than eight DCCP-Syncs per
   second.

MAY
   also leave the RESPOND state for CLOSED after a timeout of not less
   than 4MSL (8 minutes); when doing so, it SHOULD send a DCCP-Reset
   with Reset Code 2, "Aborted", to clean up state at the client.

   o  Receivers MAY rate-pace their acknowledgements rather than send
      acknowledgements immediately upon the receipt of data packets.
      Receivers that rate-pace acknowledgements SHOULD pick a rate that
      approximates the effect of Ack Ratio and SHOULD include Elapsed
      Time options (Section 13.2) to help the sender calculate round-
      trip times.
The HC-Sender SHOULD NOT increase its sending rate for approximately
   one round-trip time after seeing a packet with a Slow Receiver

Ack Ratio defaults to two. 

The cwnd parameter is initialized to at most four packets for new
   connections, following the rules from [RFC3390]; the ssthresh

   o  Drop Code 2 ("receive buffer drop").  The congestion window "cwnd"
      is reduced by one for each packet newly acknowledged as Drop Code
      2, except that it is never reduced below one.

   o  Exiting slow start.  The sender MUST exit slow start whenever it
     receives a relevant Data Dropped or Slow Receiver option.

For every RTT containing a DCCP-Ack congestion event (that is, a lost or
   marked DCCP-Ack), the sender halves the acknowledgement rate by
   doubling Ack Ratio; for every RTT containing no DCCP-Ack congestion
   event, it additively increases the acknowledgement rate through
   gradual decreases in Ack Ratio.

Ack Ratio always meets three constraints: (1) Ack Ratio is an
   integer.  (2) Ack Ratio does not exceed cwnd/2, rounded up, except
   that Ack Ratio 2 is always acceptable.  (3) Ack Ratio is two or more
   for a congestion window of four or more packets.
   The sender changes Ack Ratio within those constraints as follows.
   For each congestion window of data with lost or marked DCCP-Ack
   packets, Ack Ratio is doubled; and for each cwnd/(R^2 - R)
   consecutive congestion windows of data with no lost or marked DCCP-
   Ack packets, Ack Ratio is decreased by 1.  (See Appendix A for the

DCCP TFRC:

   The sender starts in a slow-start phase, roughly doubling its allowed
   sending rate each round-trip time.  The slow-start phase is ended by
   the receiver's report of a data packet drop or mark, after which the
   sender uses the loss event rate to calculate its allowed sending
   rate.

PLPMTUD:

Some protocols might be extended to allow arbitrary padding with
   dummy data.  This greatly simplifies the implementation because the
   probing can be performed without participation from higher layers and
   if the probe fails, the missing data (the "probe gap") is ensured to
   fit within the current MTU when it is retransmitted.  This is
   probably the most appropriate method for protocols that support
   arbitrary length options or multiplexing within the protocol itself.
   
Each Packetization Layer MUST determine when probing has converged,
   that is, when the probe size range is small enough that further
   probing is no longer worth its cost.  When probing has converged, a
   timer SHOULD be set.  When the timer expires, search_high should be
   reset to its initial value (described above) so that probing can
   resume.  Thus, if the path changes, increasing the Path MTU, then the
   flow will eventually take advantage of it.  The value for this timer
   MUST NOT be less than 5 minutes and is recommended to be 10 minutes,
   per RFC 1981.

WTCP:

It detects wireless-related problems (such as lost or corrupted segments due to
multipath fading or high Bit-Error Rate) with the use of timeouts and duplicate
acknowledgments. WTCP then attempts to mitigate the problem by retransmitting
a lost segment only once, until it receives an acknowledgment back from the
mobile host that it was received. Any other lost segments will have to wait
in the WTCP's buffer until the first one is confirmed to have been received.

There are times when packets will sit in WTCP's buffer for many milliseconds.
In order to avoid having either TCP end host go into its congestion avoidance
mode, (due to TCP looking at a segment's timestamp and determining that it took
a long time to arrive, therefore wrongly assuming it's due to congestion) WTCP
uniquely hides the time spent by the packets at the WTCP proxy, so that the
RTT estimation is not affected. 

XTP:

the quality of service in satellite communications is sometimes lacking.
XTP addresses these issues in a variety of ways such as a Selective
Retransmission algorithm that deals with loss recovery. This works by the
receiver detecting missing data packets and transmitting a list of those
missing packets to the sender, who then is able to quickly resend missing
packets as needed.

SST:

One 8-bit channel number for each direction of communication distinguishes 
different channels for one session: thus, a channel is uniquely identified by
the 4-tuple of (local endpoint, local channel, remote endpoint, remote channel).
Each channel represents a separate instance of the SST channel protocol
resulting from a successful key exchange and feature negotiation using the
negotiation protocol; SST’s channels are therefore analogous in function  to
security associationsin IPsec [17]. Different channels always use independent 
symmetric keys for encryption and authentication and may use entirely different
encryption and authentication schemes or other optional negotiated protocol
features.
A given channel always uses one set of symmetric keys and negotiated
parameters, however:  when SST needs to re-key a communication session (e.g.,
to ensure freshness of symmetric keys), it does so by creating a new channel
through a fresh run of the negotiation protocoland terminating use of the old
channel. SST may keep multiple channels active at once to allow applications
to select different security parameters for different streams, fully encrypting
and authenticating sensitive streams for security while leaving less-sensitive
streams in cleartext and only weakly checksummed for maximum efficiency,
for example.

For flow control purposes, hosts treat the data in any Init packet as belonging
to the parent stream — the stream specified in the packet’s main LSID field -
even though the data itself is semantically associated with the newchild stream
being created. In effect, when a host immediately sends data on a new stream
without waiting for the responder to acknowledge the Init packet and provide
a starting window size for the new stream, the sender effectively "borrows"
from the parent stream's receive window to send this initial data.  This
borrowing behavior is essential to maintaining proper flow control and
avoiding overrunning the receiver's buffers while allowing stream creation
with no round-trip handshaking delay.

4.16 Best-Effort Datagrams without incurring the overhead of storing and
retransmitting lost packets in the sender. In real-time streaming media
applications, for example, a lost data frame is likely to be useless after
incurring a round-trip retransmission delay, so it is better for the
receiver just to skip or tryto “fill in” for lost frames. In SST, a datagram
is semantically just an ephemeral stream that the application creates, uses
to transmit a sequence of bytes all at once, and then forcefully resets
without ensuring that the data arrives successfully or waiting for any
associated response from the receiver. A host transmits a datagram by
sending a series of Datagram Packets, each having the format shown in
Figure 16. The series of packets representing a single datagram must be
contiguous in packet sequence number space, and thus cannot be intermixed
with packets for other streams sent on the same channel. The first packet
in the series has the Begin (B) flag set, and the last packet has the
End (E) bit set; a datagram that fits entirely in one packet has both flags
set. Each packet contains the LSID of the parent stream within which the
datagram is to be transmitted: i.e., the parent of the implicit, ephemeral
stream logically containing the datagram’s content itself.

^-- same problem as in SCTP before I-DATA/partial delivery - HoL blocking here

sender includes in the packet's Acknowledgment Sequence Number (ASN) field the
low 24 bits of its current receive sequence number, indicating the highest
numbered packet it has received so far. When sending an explicit acknowledgment
for a particular packet (not necessarily having the highest sequence number
received so far), the sender places the transmit sequence number (TSN) of the
packet to be acknowledged into the ASN field of the acknowledgment. In either
case, the sender may indicate in the 4-bit AckCt field the number of consecutive
sequence numbers immediately prior to the specified ASN that it has also
received. In this way the sender may acknowledge multiple consecutive packets
at once and provide some redundancy against lost acknowledgments.

Since all packets in SST including retransmissions get fresh packet sequence
numbers, upon receiving an acknowledgment the sender can tell *exactly* which
copy (or copies) of a retransmitted packet arrived at the receiver.
The sender can use this information to detect quickly when it has incorrectly
retransmitted a packet that was in fact merely delayed rather than dropped,
and dynamically adjust it's "packet delay threshold" for fast retransmission
according to observed line conditions instead of just using TCP's conventional
"three duplicate ACK" rule [2].

^-- опять как в DCCP

The checksum algorithm used is inspired by the Adler-32 algorithm [10], but
modified to increase its entropy for small payloads, which are likely to be
common in the case of SST's channel protocol. In essence, the modified
algorithm operates on sequence of 16-bit words instead of bytes, padded with
a trailing 0x80 byte or 0x8000 word depending on whether the length of the
input is odd or even, and it uses a prime modulus of 65537 instead of 65521
to ensure that all 2^16 input data values are distinguishable. Since this is
a 17-bit rather than a 16-bit prime modulus, the final checksum consists of
the low 16 bits of each of the two resulting 17-bit counters. Pseudocode for
the algorithm is shown in Figure 20. As with Adler-32, the modulo operations
can be removed from the inner loop by using larger counters and performing
the modulo operation less frequently. With unsigned 32-bit counters, the
modulo operation needs to be performed once every 361 words to prevent the
counters from overflowing; with unsigned 64-bit counters, the modulo operation
is necessary only once every 23,730,841 words. If the counters are signed,
the period is 254 words for 32-bit counters and 16,781,438 words for 64-bit
counters.


QUIC:
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
 wishes to send data but is unable to do so due to stream-level flow
 control.  This frame is analogous to DATA_BLOCKED (Section 19.12).

A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when
   it wishes to open a stream but is unable to do so due to the maximum
   stream limit set by its peer; see Section 19.11.  A STREAMS_BLOCKED
   frame of type 0x16 is used to indicate reaching the bidirectional
   stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to
   indicate reaching the unidirectional stream limit.


TBD из DCCP выходит, что лучше бы каждой ретрансмиссии новый номер, но
кэширование (e.g. HTTP) с этим конфликтует... сделать таймаут, в течение которого
номер пакета не меняется (пакет тот же), секунд 10? 20? параметр от бэкенда?
TODO а в ICMP наоборот, для каждой ретрансмиссии нужен новый --> флаг бэкенда
  TBD или даже не флаг, а допустимое время кэша в ms - 0 будет "новый всегда"

TBD что делать, если MTU сбросился ниже размера чанков в очереди?
ответ: опция фрагментации станет обязательной

TBD в SST можно некоторым стримам назначиться в cleartext, поддержать?
- yes

TBD если вводить атрибут reply, нужно и окно и для блоковых потоков: в SST
окна для каждого, как и в ssh - сделать отдельный чанк и бит окна
в байтах/блоках?

DTLS [RFC 6347]:
   -  If repeated retransmissions do not result in a response, and the
      PMTU is unknown, subsequent retransmissions SHOULD back off to a
      smaller record size, fragmenting the handshake message as
      appropriate.  This standard does not specify an exact number of
      retransmits to attempt before backing off, but 2-3 seems
      appropriate.

EAP:
   In order to dynamically estimate the EAP retransmission timer, the
   algorithms for the estimation of SRTT, RTTVAR, and RTO described in
   [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with
   the following potential modifications:

   [a] In order to avoid synchronization behaviors that can occur with
       fixed timers among distributed systems, the retransmission timer
       is calculated with a jitter by using the RTO value and randomly
       adding a value drawn between -RTOmin/2 and RTOmin/2.  Alternative
       calculations to create jitter MAY be used.  These MUST be
       pseudo-random.  For a discussion of pseudo-random number
       generation, see [RFC1750].

   [b] When EAP is transported over a single link (as opposed to over
       the Internet), smaller values of RTOinitial, RTOmin, and RTOmax
       MAY be used.  Recommended values are RTOinitial=1 second,
       RTOmin=200ms, and RTOmax=20 seconds.

TBD [RFC 5247] EAP key Management Framework

TBD проблема DDoS-атак при прозрачном переключении эфемерного адреса: attacker
копирует body of valid packet so e.g. MAC will be correct, and changes
src IP/port to victim - server responds to victim
 -> path validation: отвечаем LINK_INFO с Address Changed и Packet Counter и
    добавляем HEARTBEAT, дальше как в SCTP, проверяем на свежий Packet Counter,
    если он со старого адреса - fail; размер невелик, так что не DDoS
  - а если attacker скопирует и этот packet, наугад?..
  - а как он его получит, если он не on path to victim?
  - нет, LINK_INFO слать на старый адрес, на новый чисто как в SCTP;
    предусмотреть ответ клиента "ниче я не менял" ?

TBD FEC


RFC 7540                         HTTP/2                         May 2015
   For example, if the client sends 60 KB immediately on connection
   establishment and the server sets the initial window size to be 16
   KB, the client will recalculate the available flow-control window to
   be -44 KB on receipt of the SETTINGS frame.  The client retains a
   negative flow-control window until WINDOW_UPDATE frames restore the
   window to being positive, after which the client can resume sending.


RFC 4821:
   Because there is some small risk that suppressing congestion control
   might have unanticipated consequences (even for one isolated loss),
   it is REQUIRED that probe failure events be less frequent than the
   normal period for losses under standard congestion control.
   Specifically, after a probe failure event and suppressed congestion
   control, PLPMTUD MUST NOT probe again until an interval that is
   larger than the expected interval between congestion control events.
   See Section 4 for details.  The simplest estimate of the interval to
   the next congestion event is the same number of round trips as the
   current congestion window in packets.


RFC 4423:
   7.  If we add an additional layer, would it make the address list in
       Stream Control Transmission Protocol (SCTP) unnecessary?
          Yes.
-- but it still may be useful for several paths *at the same time* as SCTP at
that time had just failover instead of Multilink

   9.  What would the resolution mechanisms be, or what characteristics
       of a resolution mechanisms would be required?
          For most purposes, an approach where DNS names are resolved
          simultaneously to HIs and IP addresses is sufficient.
          However, if it becomes necessary to resolve HIs into IP
          addresses or back to DNS names, a flat resolution
          infrastructure is needed.  Such an infrastructure could be
          based on the ideas of Distributed Hash Tables, but would
          require significant new development and deployment.
-- well, that's a problem...

   There has been considerable bad experience with distributed ACLs that
   contain public-key-related material, for example, with Secure SHell
   Protocol (SSH).  If the owner of a key needs to revoke it for any
   reason, the task of finding all locations where the key is held in an
   ACL may be impossible.  If the reason for the revocation is due to
   private key theft, this could be a serious issue.
 
   A host can keep track of all of its partners that might use its HIT
   in an ACL by logging all remote HITs.  It should only be necessary to
   log responder hosts.  With this information, the host can notify the
   various hosts about the change to the HIT.  There has been no attempt
   to develop a secure method to issue the HIT revocation notice.



/=== quotes from other protocols ===

6. User Data Transmission

  Mostly identical to Section 6 of RFC 4960 (pages 73-93), no need to copy
  here 20 pages of text for draft.

  so only differences here
TODO

TODO Packet Cache Lifetime - MUST be less than MSL of this network type

7.  Congestion Control

  Mostly identical to Section 7 of RFC 4960 (pages 93-100), no need to copy
  here 7 страниц текста A4. См. оригинал.

see also RFC 3517 which has more proper definition than SCTP spec of e.g.
what is flightsize, "pipe" in TCP's terminology (when byte counted twice),
also RFC 2581
and RFC 7323 for updated TCP timestamps/RTO

RFC 4341 (DCCP CCID2):
   Section 12.2.  Information about marked packets is also returned in
   the Ack Vector.  Because the information in the Ack Vector is
   reliably transferred, DCCP does not need the TCP flags of ECN-Echo
   and Congestion Window Reduced.

ACK Ratio changing as handling congestion on return path

RFC 4653 Improving the Robustness of TCP is about raising DupThresh count > 3:
     * The requirement imposed by TCP for almost in-order packet
       delivery places a constraint on the design of future technology.
       Novel routing algorithms, network components, link-layer
       retransmission mechanisms, and applications could all be looked
       at with a fresh perspective if TCP were to be more robust to
       segment reordering.  For instance, high-speed packet switches
       could cause resequencing of packets if TCP were more robust.
       There has been work proposed in the literature explicitly to
       ensure that packet ordering is maintained in such switches (e.g.,
       [KM02]).  Also, link-layer mechanisms that attempt to recover
       from packet corruption by retransmitting could be allowed to
       reorder packets, and thus increase the chances of local loss
       repair rather than rely on TCP to repair the loss (and,
       needlessly reduce its sending rate).  Additional examples include
       multi-path routing, high-delay satellite links, and some of the
       schemes proposed for a differentiated services architecture.  By
       making TCP more robust to non-congestion events, TCP-NCR may open
       the design space of the future Internet components.


8. Обработка сбоев.

  Mostly identical to Section 8 of RFC 4960 (pages 100-104), no need to copy
  смысла копировать 4 страницы текста A4.

TODO отличия in sections 8.4 and 8.5

9. Терминирование (завершение) ассоциации.

  Mostly identical to Section 8 of RFC 4960 (pages 106-110), no need to copy
  смысла копировать 5 страниц текста A4.

TODO описать отличия из-за клиент-серверной асимметричности

10. Интерфейс (API) с кодом пользователя (вышележащим уровнем).

  Подразделяется на две части: нотификации от muSCTP пользователю, и вызовы
  функций muSCTP пользователем.

TBD конкретный вид пока не определен, это более концепт-набросок

  Предполагается, что muSCTP работает в собственном отдельном треде, который
  играет роль "ядра" для обычных сокетов - вызовы оперируют на хэндле инстанса
  и блокируются (mutex) на время вызова, но построены так, чтобы быть аналогом
  неблокирующихся функций на сокетах.

10.1. Нотификации пользователю от muSCTP.

TBD думалось, что укладывается в 128 - затем, чтобы реализация была возможна
  как передачей ровно 1 байта по специальному сокету (нет проблемы блокировки
  при ожидании большего количества), так и пачкой SetEvent() не более
  максимального лимита для WaitForMultipleObjects() на Win32.

TODO re-do

  Для основной части нотификаций в младших 4 битах указан номер потока, на
  котором произошло событие, далее обозначаемый как Stream ID.

    1            - SEND FAILURE
    2            - NETWORK STATUS CHANGE
    3            - COMMUNICATION UP
    4            - COMMUNICATION LOST
    5            - COMMUNICATION ERROR
    6            - BLOCK/BYTESTREAM RECONFIGURED
    7            - QOS QUEUE READ CONFIRMED
    8            - SEND BUFFER AVAILABLE
    9            - SHUTDOWN FROM PEER
    10           - SHUTDOWN COMPLETE
    11           - ATOM CREATED
    12           - ATOM VALUE CHANGED
    13           - ATOM DELETED
    14           - CHANNEL GLOBAL REQUEST
    15           - CHANNEL EVENT
TBD

  После получения большинства из нотификаций необходимо вызвать
  соответствующую функцию для ее чтения (например, параметров реконфигурации
  потока).

TODO переделать начисто

TBD with using MSG_OOB for first part of message, that is, control data valid; MSG_EOR
for last - is it possible to use single function for partial delivery
receiving?
TBD why offset be exactly 20 bits? that's only for periodical saving, but M_GET could be any?
^ offset size is API question or move to section 4.2 ?


10.2. Доступные для вызова пользователем функции muSCTP.

10.2.1. Инициализация.

    HANDLE musctp_Init(список локальных адресов/бэкендов)

  Возвращает HANDLE треда, в котором будет работать "ядро".

typedef struct muSCTP* HANDLE

10.2.2. Установить ассоциацию (соединение).

    muSCTP* musctp_Associate(HANDLE instance, адрес назначения)

  Инициирует установление ассоциации, аналог connect() для tcp. Принимает
  адрес назначения и инстанс треда, аллоцирует и возвращает структуру
  muSCTP, играющую роль хэндла для всех остальных вызовов.

10.2.3. Корректное завершение ассоциации.

    int musctp_Shutdown(muSCTP* assoc_id)

  Подать команду на корректное завершение всей ассоциации. Тред продолжит
  работать и доставлять данные из очереди пиру.

10.2.4. Принудительный обрыв ассоциации.

    int musctp_Abort(muSCTP* assoc_id)

  Выкинуть все данные в очереди и послать чанк ABORT пиру.

10.2.5. Отправить блок данных.

    int musctp_BlockSend(muSCTP* assoc_id,
                   __in  void *buf,
		   __in  unsigned length,
		   __in  BYTE StreamID,
               __in_opt  DWORD PayloadProtoID,
               __in_opt  uintptr_t context,
	       __in_opt  BYTE QoS,
              __out_opt  WORD *SSN
    )

    int musctp_BlockUnorderedSend(muSCTP* assoc_id,
                   __in  void *buf,
		   __in  unsigned length,
		   __in  BYTE StreamID,
               __in_opt  DWORD PayloadProtoID,
               __in_opt  uintptr_t context,
	       __in_opt  BOOL Priority,		// TBD
              __out_opt  WORD *SSN
    )

  Поместить в очередь на отправку в указанный номер потока блок, полностью
  заданный на момент отправки, буфером и длиной.
  Принимает опциональный контекст - значение не интерпретируется (можно дать
  число или указатель). Контекст, если он не нулевой, будет возвращен после
  нотификации об ошибке отправки, или же при подтверждении обработки блока
  получателем, если применяется QoS. Опционально в переменную SSN можно
  получить назначенный нашим muSCTP при отправке Stream Sequence Number.

  PayloadProtoID никак не подвергается обработке (в т.ч. порядка байт) и может
  быть, например, просто ASCII-строкой из 4 байт.


10.2.6. Получить блок данных.

    int musctp_BlockRecv(muSCTP* assoc_id,
                   __in  void *buf,
		   __in  unsigned buflength,
		   __in  BYTE StreamID,
		  __out  BOOL *partial, 
              __out_opt  WORD *SSN,
	      __out_opt  BOOL *unordered,
	      __out_opt  BYTE QoS,
              __out_opt  DWORD *PayloadProtoID
    )

  Получить блок данных из указанного StreamID. Вернёт длину полученных данных,
  флаги unordered (от отправителя) и partial, если размер буфера был
  недостаточен для получения полного блока. Если блок был не unordered, то в 
  SSN (при не-NULL) будет помещен его номер (он может валидно равняться нулю!).

  Для больших блоков, не влезающих за раз, одной этой функции недостаточно.

10.2.7. Отправить байты в поток.

    int musctp_ChannelWrite(muSCTP* assoc_id,
                   __in  void *buf,
		   __in  unsigned length,
		   __in  BYTE StreamID
    )

  Полный аналог функций write() или send() для TCP-сокетов. Отправляет байты
  как байты, а не блоки, в указанный поток, если тот был переведен в потоковый
  режим. Может, соответственно, вернуть меньше записанных байт, чем просили,
  если нет места в буфере отправки.

10.2.8. Получить байты из потока.

    int musctp_ChannelRead(muSCTP* assoc_id,
                   __in  void *buf,
                   __in  unsigned length,
		   __in  BYTE StreamID
    )

  Полный аналог функций read() или recv() для TCP-сокетов. Получает байты
  как байты, а не блоки, из указанный поток, если тот был переведен в потоковый
  режим. Вернет сколько удалось поместить в буфер.

10.2.9. Информация о потоке без чтения.

    int musctp_Peek(muSCTP* assoc_id,
		   __in  BYTE StreamID,
	           __in  BOOL unordered,
		  __out  DWORD *full_length,
	      __out_opt  BYTE *QoS,
              __out_opt  WORD *SSN,
               __in_opt  void *buf,
	       __in_opt  unsigned buflength
    )

  Позволяет "подглядывать" в голову потока, не читая из него данные. Например,
  чтобы получить полный размер ожидаемого блока. Если был передан буфер,
  поместит в него начало данных, не вычитывая их.

10.2.10. Получить дальнейшую часть большого блока.

    int musctp_BlockRecvPart(muSCTP* assoc_id,
                   __in  void *buf,
		   __in  unsigned buflength,
		   __in  BYTE StreamID,
              __out_opt  DWORD *offset,
		  __out  BOOL *final, 
              __out_opt  WORD *SSN,
	      __out_opt  BOOL *unordered,	// TBD delete - size limit
    )

  Если musctp_RecvBlock() сообщил о не влезшем в буфер целиком блоке, или же
  musctp_Peek() показывает, что отправитель шлёт очень большой блок, который
  ни в один наш буфер за раз не влезет, то продолжить чтение куска после
  musctp_RecvBlock() можно этим вызовом. В final будет сообщено, если это
  последний кусок блока, в опциональном offset можно узнать, по какому
  смещению блока произошло это вычитывание. В остальном аргументы такие же.

10.2.11. Отправить дальнейшую часть большого блока.  

TODO

10.2.12. Отправить запрос на открытие канала (аналог connect() в TCP).

    int musctp_ChannelOpen(muSCTP* assoc_id,
		   __in  BYTE StreamID,
               __in_opt  DWORD BufferLimit,
               __in_opt  DWORD PayloadProtoID,
	       __in_opt  struct cbar_node *RequestParams
    )

  Данный вызов отправляет запрос на другой конец соединения об открытии
  канала - байтового потока tcp-like, с номером StreamID. Опционально можно
  передать размер буфера, которым ограничить peer-а в отправке байт в поток,
  и PayloadProtoID, а в случае, если его недостаточно - параметры в формате
  CBAR (будут автоматически кодированы из переданного дерева).

10.2.13. Peer произвёл переконфигурацию между блочным и поточным режимом.

    int musctp_ChannelEvent(muSCTP* assoc_id,
		  __out  BYTE StreamID,
		  __out  BYTE what,
              __out_opt  DWORD PayloadProtoID
    )

  Над потоком StreamID была произведена операция what вызовом
TBD   нами либо другим концом соединения, значения
  параметров точно такие же. Данное уведомление необходимо вызывать затем,
  что peer, например, мог не принять наше включение байтового потока и
  сбросить его.

10.2.14. Получить/установить параметр протокола.

    int musctp_GetParam(muSCTP* assoc_id,
номер операции
значение
транспортный адрес
    )

  Аналог getsockopt()

TODO

10.2.15. Получить информацию о сбое отправки.

    int musctp_Unsent(muSCTP* assoc_id,
              __out_opt  uintptr_t context,

TODO

10.2.16. Подтвердить обработку блока отправителю.

    int musctp_BlockConfirm(muSCTP* assoc_id,
		   __in  BYTE StreamID,
                   __in  WORD *SSN
    )

  Послать отправителю сообщение о подтверждении обработки нами блока
  в StreamID с номером SSN, чтобы им могли быть освобождены ресурсы очереди
  в сессии, если применяется QoS.

  Подтверждения очереди QoS существуют только для обычных блоков, т.е. не для
  Unordered и не для tcp-like byte streams.

10.2.17. Получить подтверждение обработки блоков получателем.

    int musctp_QueueReadConfirmed(muSCTP* assoc_id,
		   __in  unsigned count,
                  __out  uintptr_t *contexts
    )

  Поместить в буфер contexts, размер которого count, подтверждения об
  обработке отправленных нами блоков получателем, чтобы нами могли быть
  освобождены ресурсы очереди в сессии, если применяется QoS. Вернет число
  помещенных в буфер контекстов (возможно, ноль, если не было новых
  подтверждений).

10.2.18. Получить/создать атом.

    int musctp_InternAtom(muSCTP* assoc_id,
		   __in  BYTE class,
		   __in  char *name,
		   __in  BYTE *nameLen,
	       __in_opt  BOOL create
    )

TBD это же запрос на ту сторону, как возвращать результат?

10.2.19. Получить/установить значение для атома.

    int musctp_AtomCtlValue(muSCTP* assoc_id,
		   __in  BYTE class,
		   __in  BYTE atom,
		   __in  BOOL PeerToo,
	       __in_opt  WORD *path,
	       __in_opt  BYTE *pathlen,
		  __out  void *old,
		  __out  WORD *oldlen,
		   __in  void *new,
		   __in  void *newlen
    )

  Для атома с классом class и номером atom получить его старое значение
  (байтовую строку) и/или задать новое значение, возможно, не только у себя,
  но и у пира. Если значение атома было в CBAR, опционально можно получить
  и/или изменить только часть полного значения - "путь" индексами в массивах
  задается в path, размер которого pathlen (не больше 7). Это позволяет иметь
  значения размером больше, чем поддерживаемые протоколом десятки Кб.

TBD это же запрос на ту сторону, как возвращать результат?

TBD message with TTL can disappear after notification, how to handle this?
always non-blocking?

TODO

10.3. Вспомогательные функции.

    int cbar_encode(struct cbar_node *root, void *buf, int *len);
    int cbar_decode(struct cbar_node **root, void *buf, int len);

  Закодировать буфер в CBAR или раскодировать его, в дерево узлов:

    struct cbar_node {
    	WORD cn_length;	/* allocated size of this node, 8+4366*sizeof(void*) max */
	WORD cn_count;	/* number of elements, if array */
	BYTE cn_type;	/* string, atom, int or array */
	char __align[3];/* to 64 bit, so malloc at least 16 */
	union {
	    struct value_atom {	/* if atom */
	        BYTE atom_class;	/* it's Huffman number TBD 0's left?*/
	        BYTE atom_number;	/* TBD will we have >256 in class? */
	        BYTE atom_namelen;	/* 1..128 */
	        char *atom_name;	/* bytestring, not ASCIIZ */
	    };
	    BYTE	value_u8;
	    int8_t	value_i8;
	    uint16_t	value_u16;
	    int16_t	value_i16;
	    uint32_t	value_u32;
	    int32_t	value_i32;
	    uint64_t	value_u64;
	    int64_t	value_i64;
	    char	bytestring[0];
	    int8_t	array_i8[0];
	    uint16_t	array_u16[0];
	    int16_t	array_i16[0];
	    uint32_t	array_u32[0];
	    int32_t	array_i32[0];
	    uint64_t	array_u64[0];
	    int64_t	array_i64[0];
	    struct cbar_node *cbar_array[0];
	};
    };

TODO rethink, it's not CBAR & atom classes now, but some app helper still needed



References

[RFC 3080] BEEP, The Blocks Extensible Exchange Protocol Core







Appendix A. Common patterns for tunnel writers.

This section is mainly about how to do fragmentation if INIT packets,
depending on how many bits are available in your protocol.

PadLength - valid only if Pkt Size <=64 and Block1/MoreF is
NOT (11 from client OR 01 from server) - external padding to
this Ping packet size

FLI:
 00 - unfragmented
 01 - Last Indicator
 10 - 1 of 2
 11 - 2 of 2

or:

  0             7
 +-+-+-+-+-+-+-+-+
  F|N|L|  Offset
 +-+-+-+-+-+-+-+-+
  Frag, Non-First, last, Offset in 8-byte units minus 3, counting after it 
  so for maximum last will be 0xff -> offset is 31 -> (31+3)*8=272
  and 24 bytes in it -> 296 bytes total

-- variant 1:

  2 3 4 5 6 7
 +-+-+-+-+-+-+
 |Op | Frags |
 +-+-+-+-+-+-+

 Op = 00 - Transfer Frag #Frags
 Op = 01 - Answer will have #Frags
 Op = 1? - Received Bitmap, in 5 bits

  2 3 4 5 6 7
 +-+-+-+-+-+-+
 |1| Bitmap  |
 +-+-+-+-+-+-+

-- variant 2:

        2       3       4       5       6       7
    +-------+-------+-------+-------+-------+-------+
    |Block1 |Block2 | MoreF |    Fragment Number    |
    +-------+-------+-------+-------+-------+-------+

00  - unfragmented, both
01  - client get frag (MF must be 0), server answers with frag
100 - unfragmented from server? or confirming
11  -
redo for number must be in Block Counter?

-- variant 3:

    FragO:                       G/FragN: 

        1       2       3            20       21      22        23 
    +-------+-------+-------+    +--------+--------+--------+--------+
    |ContACK|  Fail | MoreF |    |Block1/2|      Fragment Number     |
    +-------+-------+-------+    +--------+--------+--------+--------+

        1       2       3    
    +-------+-------+-------+
    |   1   | ACK-1 | ACK-2 |
    +-------+-------+-------+

G=1 FragN=0 is SECOND thus 9 frags from server possible

if FragO=000 and Fragment Number != 0, then TSL|T23 is padding length

-- variant 4:

increment middle Packet Counter byte for each next fragment
Client:

        1       2       3        4        5
    +-------+-------+--------+--------+--------+
    |Block1 | MoreF |      Fragment Number     |
    +-------+-------+--------+--------+--------+

00 - unfragmented packet
01 - client get frag from server
10 - client's fragment, last
11 - client's fragment, non-last

        1       2       3        4        5
    +-------+-------+--------+--------+--------+
    |Status | MoreF | FragNum / ErrCode / Acks |
    +-------+-------+--------+--------+--------+

00 - unfragmented packet or last fragment
01 - Block2 answer client get frag, more to follow
10 - 4.xx Error Code answer: 0 for 4.08 (reasm timo) , 5 for 4.13 (too large)
11 - 2.31 Continue, bits for ACK previous, prev minus 1, prev-2

...this means 8 frags of 48 bytes = 384 - too much?

-- variant 5:

      1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+
    |G/S|Beg|End|Fragment Offset| 
    +---+---+---+---+---+---+---+

G/S - Get from Client, or Status from server
in 16 byte units minus 3 -> up to 336 bytes

client:
011 - unfragmented, Last Indicator if Offset != 0
01? - first fragment, offset is ignored
00? - client sends offset in 16 byte units minus 3 (so for second ofs=0)
100 - client gets this offset from server
1?? - ?

server:
011 - unfragmented data
01? - first fragment, offset is ignored
00? - data at offset in 16 byte units minus 3
100 - 2.31 Continue, offset is next expected client's offset (start of hole)
101 - Error, don't continue, Offset is code as CoAP 4.x (8 timo, 13 too large)
110 - reserved
111 - data at offset 336 ? then again 384 max

-- variant 6:
client:
G=0 - send unfragged or frag N, L = Last Indicator
      if FragOfs=0 then first frag
      else offset in 16 byte units minus 2, so FragOfs=1 is 48
      so last possible fragment is at (15+2)*16=272 bytes -> to 320 max
G=1 - get from server L+FragOfs=5 bit Offset - in 8 byte units minus 6
      so last possible fragment is at (31+6)*8=296 bytes -> to 344 max
at each fragment except very first, clients sends FragCookie[FragOfs] byte of
server's Fragment Cookie byte string

server (in legend N > 0):
G=1 - answer to client's request with offset L+FragOfs
G=0:
L|FragOfs
0 N    - 2.31 Continue, N is next expected client's frag (start of hole)
         server's fragment cookie is included
1 0    - unfragmented
1 N<13 - answer with first 16/32/48 bytes and there are N packets more
1 13   - Error, don't continue, 4.13 too large
1 14   - Error, don't continue, offset in G request too big
1 15   - Error, don't continue, 4.08 Timeout

-- variant 7:

frag field 5 bits, code space divided in 3 parts:

client:
N=0..9   - frag number N, last
N=10..18 - frag number N-10, non-last
N=20..30 - get from server frag number N-20
19, 31 - reserved

TBD 12 packets!

server:
N=0..10  - frag number N, last
N=11..20 - frag number N-11, non-last
N=21..29 - 2.31 Continue, received N-20 contiguous frags from client
N=30..31 - Error, don't continue, 30=Timeout, 31=Too large

---
для 32-байтного D на R в TSL; 8.3 штамп и 7 дельта (1 знак, 4 целое):
 

  TBD 

TODO


Appendix B. Example tunnel: UDP tunnels of size M and XXL.

   All UDP tunnels has first 5 bits for Version and header Size - to
   distinguish between type, to have space for future versions and to
   indicate whether header compression was

         0       1       2       3       4       5       6       7
     +-------+-------+-------+-------+-------+-------+-------+-------+...
     | Tunnel Format Version and Header Size |On-Path Device modified|
     +-------+-------+-------+-------+-------+-------+-------+-------+...

   As changes to bit widths of fields during active link are not allowed
   (e.g. Packet Counter could wrap at wrong point), tunnels MUST silently
   ignore packets with known Connection Verification Tag, but incorrect
   Version/Size field, if several Version/Size are implemented on a single
   listening UDP port.

   Also all UDP tunnels have Connection Verification Tag in second 4-byte word
   when header compression (that is, INIT) is not applied.
   TBD what with variable length tag?

size S:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VerSizS|IWL|ServInstNum|ShKeyID|ErsatzMAC|FracS| tv_sec 8 bits |
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|M|               Connection Verification Tag               |
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Packet Counter |                                               /
     +-+-+-+-+-+-+-+-+                                               \
     /             Actual packet data, probably encrypted            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IWL:
00 - INIT
01 - usual
10 - usual + Wrap Packet Counter
11 - usual + Last Indicator

TBD if ShKeyID+ErsatzMAC to Septinovile, then has space for OnPath

TBD 19.12.24 BLAKE2 allows 1-byte digest, redo VerSize coding as static Huffman so it ErsatzMAC could be more real? Of course more as a checksum, but that allows for fragments to have one AUTH chunk per several packets and to use that several packets not blindly

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VerSzXS|0 0|MSS|TSL|T23|K|PkCLo|tv_sec lo 16 bits / Low 5 PkCHi|
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /         Actual INIT packet data, probably encrypted           /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MSS - limit MTU, safe MSS is:
0    - 24 bytes (33 bytes UDP payload)
1    - 32 bytes
2    - 48 bytes
3    - 64 bytes

TBD space for crypto checksum

UDP Size M in Established state (usual packet):

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VerSizM|0|OnPat|FEC/W/L|tv_usec Hi 10 bits |H| Packet Counter  |
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|M/CRule|           Connection Verification Tag             |
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Shared Key ID|ServInstNum| tv_sec Low 11 bits  |    Nonce,     /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  optional,    \
     /                  present / defined by Key Algo                /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /             Actual packet data, probably encrypted            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /         MAC, optional, present / defined by Key Algo          /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H - has Host IDs Sum 2 bytes

FEC Num/Wrap/Last:
- 0      - packet is not under FEC
- 1..9   - data packet number for FEC
- 10..13 - this is XOR-packet for X previous FEC-packets, first of them is
  PacketCounter-X, where X is by table:
   10 = 3 packets 
   11 = 5 packets 
   12 = 7 packets 
   13 = 9 packets 
   14 = PkCntWrap
   15 = not a FEC, but L - Last Indicator

his format - XOR of _ciphertexts_ ! that is, all, except first 16 bits
coz XOR, if MUST odd number of pkts (for TSL/Tag) so allows 2 times more packets 


For all FEC data packets, there MUST be same field values for L, Tag,
Shared Key ID and ServInstNum, and MUST be same packet size.
-> which means must be L=0

TBD если это полный XOR, then on-path attacker may send false XOR-packet which
will flush FEC queue TBD and what? if on-path attacker could delete packets,
this will achieve same effect
-> report false XOR-packets (MAC failures after reconstruct) in ECNE_CWR ?

OnPat field is explicitly reserved for on-path devices to help problem of
Section 4 of [RFC 8546], thus, it MUST NOT be included in HMAC calculation
(MUST be set to zero by both sender and receiver before HMAC checking)
TBD need we consider [RFC 8558] ?


INIT/ACK-packet:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VerSizM|1|lgMSS|tv_sec low 24 bits / Low 7 as Packet Counter Hi|
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|T23|K|H|PLo|Host IDs Sum, optional (if H=1)|    Nonce,     \
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  optional,    /
     /                  present / defined if K=1 ...                 \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                    Actual INIT packet data                    /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /    MAC, opt, if K=1 - defined by Key Algo, or CRC32 if K=0   /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

T23 - bits 2/3 (R/E) from compressed Connection Verification Tag

клиент посылает первый фрагмент и включает Fragment Cookie, сервер отвечает
на него кодом 15, в котором повторяет Fragment Cookie клиента и добавляет еще
3 байта (далее возможен игнорируемый padding рандомом) - клиент будет их слать
в Fragment Cookie фрагментов 2-5; в пакетах сервера же никогда нет куки, кроме
Frags=15; при коде 15 кука интерпретируется по принципу из Tag - если все биты
нули, кроме первого, это не кука, а код ошибки - если он ноль (вся кука 0), то
это таймаут, если он 1 (кука равна 0x800000), это too large

CRC32 (algo as in SCTP) is instead of MAC when Key=0, but only if:
1) Packet is fragmented, or
2) Packet is unfragmented and is > 128 bytes in length TBD better threshold?

TBD MTU in first frag - also as Flags e.g. Public Key of K=1

TBD if variant INIT unfragged - move MTU to first byte of Fragment Cookie, which
is CoAP (?) reply code if Frags=15/error

lgMSS - limit MTU, safe MSS is:
0    - 32 bytes
1    - 48 bytes
2..6 - 2^(4+lgMSS) bytes (that is, 6 means 1024 bytes)
7 - 1248 on IPv4, 1216 on IPv6

allows ~3 Gbit/sec = 8 * 2^10 bits tv_usec * 2^(9-1) bits Packet Counter * 1500 bytes Ethernet MTU


size L - on 1280 MTU no need to separate INIT format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VerSizeXL|OnPat| Shared Key ID |    Packet Counter, 16 bits    |
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|M/CRule|            Connection Verification Tag            |
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Reservd|DIL|SIL|              tv_sec, low 24 bits              |
  12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |ServInstNum|FEC N/Wr/La|         tv_usec, full 20 bits         |
  16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .           Destination Host ID - optional, DIL words           .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .             Source Host ID - optional, SIL words              .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .        Nonce, optional, present / defined by Key Algo         .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /             Actual packet data, probably encrypted            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /         HMAC, optional, present / defined by Key Algo         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

this is exactly 1440 byte MSS on IPv4: 1472 UDP - 16 header - 16 HMAC,
with header used as nonce

size XL - for MTU >= 1500:
 
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VerSizeXL|OnPat|L|Pkt Counter Wrap |FEC Number |Reservd|DIL|SIL|
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|M/CRule|             Connection Verification Tag           |
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     tv_sec, full 32 bits                      |
  12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Shared Key ID, 12 bits|         tv_usec, full 20 bits         |
  16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |ServInstNum|           Packet Counter, full 26 bits            |
  20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .           Destination Host ID - optional, DIL words           .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .             Source Host ID - optional, SIL words              .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .        Nonce, optional, present / defined by Key Algo         .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /             Actual packet data, probably encrypted            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /         HMAC, optional, present / defined by Key Algo         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


TODO


Appendix C. Example tunnel: ICMP4 Echo/Reply ("Ping") of 64 bytes.

Recall, in ICMP v4 Echo or Echo Reply Message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

Identifier is constant for NAT traversal (it's like port), but not used
itself.

Sequence Number is used as Packet Counter, 16 bit.

В реальных ping-пакетах от Unix первые 8 байт Data используются для
timestamp в формате struct timeval (big endian, 4 на секунды и 4 на
микросекунды), их интерпретирует Wireshark, остальные данные нет, поэтому их
всегда отражаем как есть
64 байта включают заголовок ICMP, т.е. на Data только 56 байт

Dif - биты, которые обязательно должны быть разными от клиента и сервера,
для отличия от случайного попадания в обычный пинг
NOTE Dif is not needed in non-INIT packets as Tags are different

Значения полей см. в описании UDP



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     0/8       |       0       |          Checksum             |
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Identifier          |        Packet Counter         |
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | tv_sec Hi byte|  Nfewnce  |1|ServInstNum| tv_sec Low 11 bits  |
  12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    tv_usec - must be 0  |L|   Milliseconds    | Shared Key ID |
  16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /  External Packet Padding to 64 bytes, ignored on receipt,     /
     \  it's length in ExtPadlen, fill is with bytes 08 09 0a ...    \
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|R| Connection Verification Tag, XORed w/cipher if Key > 0  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /       Nonce, optional, present / defined by Key Algo          /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /             Actual packet data, probably encrypted            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /        MAC, optional, present / defined by Key Algo           /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Host IDs Sum, 20 bits         |Pkt Cntr Wrap|ExtPadLen|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

from server:
     /        MAC, optional, present / defined by Key Algo           /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Delta, Milliseconds, 0=Invalid|  Packet Counter   |W|ExtPadLen|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  PWrap - in seconds
TBD
  S - Sign of Delta
  Server Time = Packet Stamp + Delta*(-1)^S, in both directions

TBD an INIT packet needs port and HIS reflect

  INIT/ACK:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     0/8       |       0       |          Checksum             |
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Identifier          |        Packet Counter         |
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | tv_sec Hi byte|      'T'      |      tv_sec Low 16 bits       |
  12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   tv_usec - must be 0   |Fraction Secs|ExtPadlen|TSL|T23|K|Dif|
  16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /  External Packet Padding to 64 bytes, ignored on receipt,     /
     \  it's length in ExtPadlen, fill is with bytes 08 09 0a ...    \
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .      Nonce, optional, present / defined by Key Algo...        .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /             Actual packet data, probably encrypted            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /          MAC, optional, present / defined by Key Algo         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TBD FEC Num 5 bits? what with PacketCounter from server for FEC
- 0      - пакет не принадлежит FEC
- 1..21  - номер пакета с данными для FEC
- 22..31 - это XOR-пакет для X предыдущих FEC-пакетов, с первым из них в
  PacketCounter-X, где X задается по таблице:
   22 = 3 packets 
   23 = 5 packets 
   24 = 7 packets 
   25 = 9 packets 
   26 = 11 packets 
   27 = 13 packets 
   28 = 15 packets 
   29 = 17 packets 
   30 = 19 packets 
   31 = 21 packets 

TODO


Appendix D. Draft ideas of "no tunnel" but "traditional" way - directly in
IPv4/IPv6 packet.

   Starts with byte with version of this "tunnel"'s serialization,
   Checksum Coverage (and length, possibly CRC32), whether this is INIT/ACK
   packet, and if we have ports:

Полк P - наличие/компрессия дополнительных 4 байт с портами:
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |Version|CSumCov|Ini| H |  Prt  |
   +---+---+---+---+---+---+---+---+

   H - Have Ports, when 0 - no ports bytes, bit 6 is Src and 7 is Dst,
   else as in RFC 6282 Section 4.3.3

   Prt: Ports:

      00:  All 16 bits for both Source Port and Destination Port are
         carried in-line.

      01:  All 16 bits for Source Port are carried in-line.  First 8
         bits of Destination Port is 0xf0 and elided.  The remaining 8
         bits of Destination Port are carried in-line.

      10:  First 8 bits of Source Port are 0xf0 and elided.  The
         remaining 8 bits of Source Port are carried in-line.  All 16
         bits for Destination Port are carried in-line.

      11:  First 12 bits of both Source Port and Destination Port are
         0xf0b and elided.  The remaining 4 bits for each are carried
         in-line.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Source Port Number        |     Destination Port Number   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     - full 4-byte version, if Prt=00

  Why ports? While muSCTP don't use ports itself, as primary field for
  (de)multiplexing is Verification Tag, it's 29 bits may be not enough as
  a substitute for peer's address in entire Internet, if there are many
  connections. Also, consider that if same hosts participates in some
  connections as a server and in other as a client, then a need arises to
  distinguish the two. In tunneled case, both server knows e.g.
  "I am listening on UDP 1234"  and client knows "Src Port 1234 is from server",
  where addresess are got by external means. Thus, at least one bit to
  distinguish in raw IP case is required, but it is abstracted to entire
  ports, for cases there is need for  more bits of entropy in address.

TODO rewrite prev paragraph for different Tag length and also that port is
unavoidable in INIT/ACK packets
- 18.09.24 see fragmentation issues in IPnh.txt for this date, first words
  must be invariant discriminator of flow for balancers, thus Connection Tag
  for "normal peaceful Internet" (it still may be compressed in 6LoWPAN where
  there are no balancers) MUST be in first 4 bytes, changing TSL to Ver/Init

- also see RFC 8900 - e.g. ECMP and load balancers

   Following tradition of early TCP/IP, servers listen on odd ports and
   clients send from even ports. So in most compressed form, when H is 0,
   then Prt=01 is client to server packet, and Prt=10 is packet from server
   to client; following RFC 6282 way, ports are really 0xf0b0 and 0xf0b1.

   The H=0 doesn't require any NAT operations
TBD what NAT actions required if there ARE some ports?..

   Following the initial byte and ports bytes (if any), follows checksum -
   either 2 bytes of standard Internet Checksum or 4 bytes CRC32, the same
   algorithm as in SCTP [RFC 4960].

   Checksum/CRC is needed to avoid expensive cryptographic MAC computation if
   packet is corrupted in header, and also for for cases when Shared Key ID
   is 0, that is, when no encryption/MAC is in this packet.

   Next fields depend on whether this is INIT/ACK packet (I=1) or regular
   packet.

TBD why server ports? Instance number is for that, just make flag to/from
server and client port - then NAT is like for ICMP Echo/Reply
- RFC 8900 Section 3.5 problem - do Connection Tag solve it?
  - for new IP, also Section 3.8.3 Anycast problem

TBD variable length timestamp / FEC fields ?



Appendix L. Proposed "tunnel" in 6LoWPAN packet instead of IPv6.

   As muSCTP is intended to be used together with 6LoWPAN suite, not strictly
   instead, even this "instead of IPv6+UDP" mode is still registered in
   6LoWPAN's NALP space of Dispatch byte. It is expected that one path between
   endpoints is via generic 6LoWPAN and other, described in this Appendix, is
   used on the same L2 segment after MAC addresses are discovered.

   Dispatch byte(s) variants:
   * 1a
   * f2a3 = page 2 (number 675)

then:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Versi|0|CsC|Shared Key ID|PacketCounter|L|W|tv_sec Low 10 bits |
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |TSL|R|               Connection Verification Tag               |
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |ServInstNum| tv_usec Hi 10 bits|   Checksum, optional, by CsC  | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /         Nonce, optional, present / defined by Key Algo        /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /             Actual packet data, probably encrypted            /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /          MAC, optional, present / defined by Key Algo         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 CsC - Checksum Presence / Coverage:
 0 - absent, integrity is by outer layer
 1 - present, only header 10 bytes are covered
 2 - present, only first 16 bytes are covered: header and (part of) Nonce
 3 - present, entire packet is covered

1 and 2 are for cases when MAC is present and will catch errors

TBD in 2 - are 16 bytes enough for nonce coverage?

and INIT/ACK:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Versi|1|TSL|T23|K|   tv_usec   |           Checksum            |
   4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|    Port     | tv_sec low 24 bits / Low 7 as Packet Counter  |
   8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .        Nonce, optional, present / defined if K=1 ...          .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                    Actual INIT packet data                    /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /         HMAC, optional, if K=1 - defined by Key Algo          /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "port" field is not a real port, but serves as identificator for
   matching INIT packets and responses to them, just as if it would be
   epehemeral port for each new connection in UDP. It is not needed in
   normal operation (ConnectionTag is for this), and limits connection
   speed between two hosts to 128 attempts per MSL.

   The S flag is 1 when packet is from server (that is, INIT ACK), and
   zero if it is INIT from client.

TODO

TBD generalized endpoint, server system


TODO


Appendix F. Fragmentation techniques TBD put all abandoned ideas here?


INIT Fragmentation 
10/11 frags, 5 bit 
Offsets in 6 bits  
5 frags in 4 bits  
2-3 frags, 2-3 bits
None               
None               

а в бэкендах можно 2 бита на max.2 фрагмента и четвертое как Last Indicator

   0 - 1/1 - Unfragmented          0 - normal data
   1 - 1/2                         1 - normal data, Last Indicator
   2 - 1/3                         2 - INIT/ACK, Unfragmented
   3 - 1/4                         3 - INIT/ACK, Frag 1 of 2
   4 - 1/5                         4 - INIT/ACK, Frag 2 of 2
   5 - 2/2                         5 - INIT/ACK, Frag 1 of 3
   6 - 2/3                         6 - INIT/ACK, Frag 2 of 3
   7 - 2/4                         7 - INIT/ACK, Frag 3 of 3
   8 - 2/5
   9 - 3/3
  10 - 3/4
  11 - 3/5
  12 - 4/4
  13 - 4/5
  14 - 5/5
  15 - Error/fragcookie



TODO

Appendix I. Different sub-byte variable integers.

2 for only VERY short (4/6/8 bits total, 0..63)

3,4,5,6 bits - 7 is too long to converge

I.2. VarNibble.

   This is a variable-length integer encoding on the sub-byte resolution. It
   occupies integral number of nibbles and utilizes addition scheme in
   a manner similar to CoAP [RFC 7252] option delta encoding: the lowest
   possible values are encoded as themselves, and at each increasing of length
   value zero of expanded bitfield is total 

The LLVM documentation describes a field that uses 4-bit chunk, with each chunk consisting of 1 bit continuation and 3 bits payload.[9]

   Enconding                                               Total values / zero
                                                           of next level's
      0                                                    Biased Value
      0 1 2 3
     +-+-+-+-+
     | 0..9  | Integers from 0 to 9, themselves
     +-+-+-+-+

      0               
      0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+
     |  0xa  |B.Val. | Integer Values from 10 to 25            10 + 16 = 26
     +-+-+-+-+-+-+-+-+

      0
      0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+
     |  0xb  | Biased Value  | Integer Values from 26 to 281   26 + 256 = 282
     +-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  0xc  | Biased Value, 12 bits | ...and so on            282 + 4096
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  0xd  |     Biased Value, 16 bits     |                 4378 + 65536
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  0xe  |         Biased Value, 20 bits         |         69914 + 1048576
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  0xf  |             Biased Value, 24 bits             | 1118490 + 2^24
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For example, integer value 17 is encoded as two nibbles 0xa7, and value 42
   is encoded as three nibbles 0xb14.


 0..9
 1010 bbbb cccc                           - 8
 1011 bbbb cccc dddd eeee                 - 16
 11aa bbbb cccc dddd eeee ffff gggg       - 26

 0..7
 10aa bbbb                                - 6
 110a bbbb cccc                           - 9
 1110 bbbb cccc dddd                      - 12
 1111 0bbb cccc dddd eeee                 - 15 in 20
 1111 10bb cccc dddd eeee ffff gggg       - 22 in 28
 1111 11bb cccc dddd eeee ffff gggg hhhh  - 26 in 32

 0..7
 1000 bbbb cccc                           - 8
 1001 bbbb cccc dddd                      - 12
 1010 bbbb cccc dddd eeee                 - 16
 1011 bbbb cccc dddd eeee ffff            - 20 in 24
 11aa bbbb cccc dddd eeee ffff gggg       - 26

 0..7
 100a bbbb                                - 5
 1010 bbbb cccc                           - 8
 1011 bbbb cccc dddd                      - 12
 11aa bbbb cccc dddd eeee ffff gggg       - 26

 0..9
 101a bbbb                                - 5
 1100 bbbb cccc dddd                      - 12
 1101 bbbb cccc dddd eeee                 - 16
 1110 bbbb cccc dddd eeee ffff            - 20
 1111 bbbb cccc dddd eeee ffff gggg       - 24

VarSextet combined?
 0..7
 10aa bbbb cccc                           - 10 in 12
 1100 bbbb cccc dddd eeee                 - 16 in 20
 1101 bbbb cccc dddd eeee ffff            - 20 in 24
 1111 xxbb                          8..19 - in 8
 1111 11bb cccc dddd eeee ffff gggg hhhh  - 26 in 32

as ranges in byte?
 0..7
 1xxa bbbb                                - 6- not till end, 96 vals
 111x xxbb cccc dddd
 111x xxbb cccc dddd eeee                 - 14
 1111 11bb cccc dddd eeee ffff gggg hhhh  - 26 in 32

 0..9
 1010 11bb cccc dddd eeee ffff gggg hhhh  - 26 in 32
 1010 10bb cccc dddd eeee ffff gggg       - 22 in 28
 1010 0bbb cccc dddd eeee ffff            - 19 in 24
 1011 bbbb cccc dddd eeee                 - 16 in 20
 11aa bbbb cccc                           - 10

 0..9
 1010 aaaa                                - 10 + 16 = 26
 1011 00bb cccc dddd eeee                 - 14 in 20
 1011 01bb cccc dddd eeee ffff            - 18 in 24
 1011 10bb cccc dddd eeee ffff gggg       - 22 in 28
 1011 11bb cccc dddd eeee ffff gggg hhhh  - 26 in 32
 11aa bbbb cccc                           - 10

TBD 11xxbbbbcccc - 768 from 10 bits

TBD 13.02.25 23:00 https://arxiv.org/pdf/2111.12800 about tiny pointers
describes a way of storing bitmap/sizes of pointers, the idea of O(log N)
counts of sizes - may apply this, but VarNibbles array must be sorted for this
and to restore order permutation requires O(log(N!)) ~= O(N^2) space - too
much... however this reminds of Burrows–Wheeler and Move-to-front transforms
- storing a bitmap where each integer starts/ends (just concatenated bitmaps)
  is no different in space in continuation bit in each nibble (like
  SDNV/DER/OID for bytes); if represent as digits-with-commas and encode
  length separate - it's again not different from storing length directly in
  our VarNibble in overall storage, just gives possibility of non 2^N lengths
- huh, bzip2 is complex, two RLE steps...
TBD 14.02.25 01:30 what if instead of length in every integer apply zeroes
compression? while BWT and MTF may be to complex, RLE may be enough:
represent as a string of hex digits, convert every 2+ sequence of 0's to
two nibbles <0 count> or bare 0 if it was just one zero in original, and
then store additional bitmap: for every 0 in stream, bit 0 if it is bare 0
and bit 1 if it is followed by count nibble
* pro: it can also compress zeroes at ends of numbers
  - 15.08.25 04:15 and it's quite possible in SKIP_BLOCKS because
    Delta to next SSN is followed by nibble-sized Bitmap, so should consider
    changing there from VarSextets to VarNibbles
* con: worst case of alternating 0 and non-0 nibbles expands by bit per byte
  - may be mitigated by a flag in type byte (we anyway need to store length of
    bitmap) that is not compressed, so this will be better than 12.5% starting
    from 9 bytes
- 18.02.25 02:15 bitmap may be split "streaming": a bitmap byte, then chunk of
  nibbles, as 7 zeroes (including count if any) were seen, another bitmap
  byte, and so on (first bit is flag if compressed, then bitmap, else number
  of bytes) - this is almost same for decoder but simpler for encoder as
  there is no need to return to initial bytes which are variable-length (so
  encoded portion need to be memmove()ed a byte or two), because if after try
  to encode it's constant size to patch whether compression succeeded or not,
  and less to re-try, vs entire set
  - 19.02 00:15 byte is simple, but what if ended not on a byte boundary?
    issue a padding? make that padding real nibble whatever it be, even
    non-counted zero? or reduce bitmap/length to nibble itself - 3 zeroes max?
    - 00:20 then "non-compressed" variant of 8 nibbles has too much overhead,
      12.5% (though still better than CBOR)
    - 00:23 padding real nibble even if it is unbitmaped zero looks better,
      but also need to think about overall padding on stream termination...
      though simple if we got multiple of integer size unpacked, just ignore
      leftover
- 19.02.25 00:34 this scheme is better than all other VarNibbles on values
  more than byte, but worse than all other VarNibbles and even CBOR on
  particular datasets like long runs of values in at least 0-7 range: each
  uint32_t will become '0 <7> val' - that is, 3 nibbles for 1 = 150%!
  - 01:40 <type> <count> <vals> block, where <count> is of original integers,
    type is 0 for all-zeroes, 1/2/3 for that size in nibbles
    type 4..7 - single integer of <type> nibbles
    type 8,9,a,b - 1..4 full 32-bit uncompressed follow
    type <11xx xxxx> = bitmap as above, then take N nibbles from stream of
    "padding" to make it whole number of integers
  - 23.01.26 01:00 possible permutation before VarNibbles: first lowest
    nibbles of every integer, then second low, and so on to highest ones, so
    the tail likely will have many zeroes combined, but this scheme requires
    storing original size and same width for all integers
- 14.08.25 if we are fine with shorter integers than uint32_t - 24 bit - then
  a following scheme could be used: initial byte of chunk contains three
  numbers, 6*6*6=216 - lengths of three following integers, 1 to 6 nibbles;
  if we encoding very specific data, like a number could be:
  * absolute
  * plus delta
  * minus delta
  then root(65536, 5) =~ 9.18 i.e. 2 bytes for 5 integers some of which are
  absolute and some deltas
  - 04:46 this may not be combined directly but 6 nibbles could be "after
    zero oad" and contain 0 inside, and 216+32 for bitmap
  - 19.08.25 this continued in new added file nbor.txt, which covers
    VarNibbles variants and CBOR-like encoding of what was originally intended
    under name "CBAR" (until CBAR became just compression for CBOR)
TBD 18.08.25
https://arxiv.org/pdf/1209.2137v5 D. LEMIRE AND L. BOYTSOV
"2.8. Patched coding" -- linked list of overflows and array of exceptions
===

bytes?

>32:

 0..127
 10aaaaaa bbbbbbbb                                     - 14
 1100aaaa bbbbbbbb cccccccc                            - 20
 1101aaaa bbbbbbbb cccccccc dddddddd                   - 28
 1110aaaa bbbbbbbb cccccccc dddddddd eeeeeeee          - 36
 1111aaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff - 44

 0..159
 101aaaaa bbbbbbbb                             - 13
 110aaaaa bbbbbbbb cccccccc                    - 21
 1110aaaa bbbbbbbb cccccccc dddddddd           - 28
 1111aaaa bbbbbbbb cccccccc dddddddd eeeeeeee  - 36

 0..191
 110aaaaa bbbbbbbb                                                       - 13
 11100aaa bbbbbbbb cccccccc                                              - 19
 11101aaa bbbbbbbb cccccccc dddddddd                                     - 27
 111100aa bbbbbbbb cccccccc dddddddd eeeeeeee                            - 34
 111101aa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff                   - 42
 111110aa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg          - 50
 111111aa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg hhhhhhhh - 58

 0..143
 1001aaaa bbbbbbbb                                                       - 12
 1010aaaa bbbbbbbb cccccccc                                              - 20
 1011aaaa bbbbbbbb cccccccc dddddddd                                     - 28
 1100aaaa bbbbbbbb cccccccc dddddddd eeeeeeee                            - 36
 1101aaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff                   - 44
 1110aaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg          - 52
 1111aaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg hhhhhhhh - 60

 0..143
 1001aaaa bbbbbbbb                                                       - 12
 10100aaa bbbbbbbb cccccccc                                              - 19
 11aaaaaa bbbbbbbb cccccccc dddddddd                   - 30
 1010100a bbbbbbbb cccccccc dddddddd eeeeeeee                            - 33
 1010101a bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff                   - 41
 101011aa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg          - 50
 1011aaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg hhhhhhhh - 60

 0..127
 100aaaaa bbbbbbbb                                                       - 13
 10100aaa bbbbbbbb cccccccc                                              - 19
 11aaaaaa bbbbbbbb cccccccc dddddddd                   - 30
 1010100a bbbbbbbb cccccccc dddddddd eeeeeeee                            - 33
 1010101a bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff                   - 41
 101011aa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg          - 50
 1011aaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg hhhhhhhh - 60

 0..127
 100aaaaa bbbbbbbb                                     - 13
 1010aaaa bbbbbbbb cccccccc                                              - 20
 11aaaaaa bbbbbbbb cccccccc dddddddd                   - 30
 1011aaaa bbbbbbbb cccccccc dddddddd eeeeeeee                            - 36

 0..127
 100aaaaa bbbbbbbb                                                       - 13
 10100aaa bbbbbbbb cccccccc                                              - 19
 11aaaaaa bbbbbbbb cccccccc dddddddd                   - 30
 10101aaa bbbbbbbb cccccccc dddddddd eeeeeeee                            - 35
 10110aaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff                   - 43
 10111aaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg          - 51

 0..191
 110aaaaa bbbbbbbb                                                       - 13
 1110aaaa bbbbbbbb cccccccc                                              - 20
 11110aaa bbbbbbbb cccccccc dddddddd                                     - 27
 111110aa bbbbbbbb cccccccc dddddddd eeeeeeee                            - 34
 11111100 aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee                   - 40
 11111101 aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff          - 48
 11111110 aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg - 56
 11111111 aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee   ...    hhhhhhhh - 64

32:

 current:
 0..63
 01aaaaaa bbbbbbbb                                     - 14
 10aaaaaa bbbbbbbb cccccccc                            - 22
 11aaaaaa bbbbbbbb cccccccc dddddddd                   - 30

 0..127
 100aaaaa bbbbbbbb                                     - 13
 101aaaaa bbbbbbbb cccccccc                            - 21
 11aaaaaa bbbbbbbb cccccccc dddddddd                   - 30

TBD for byte-granularity memcmp-order is better - e.g. ability to sort keys
int memcmp(const void *s1, const void *s2, size_t n)
{
        if (n != 0) {
                const unsigned char *p1 = s1, *p2 = s2;

                do {
                        if (*p1++ != *p2++)
                                return (*--p1 - *--p2);
                } while (--n != 0);
        }
        return (0);
int key_compare(const void *key1, int len1, const void *key2, int len2){
  int c = memcmp(key1, key2, len1<len2 ? len1 : len2);
  if( c==0 ) c = len1 - len2;
  return c;
}


https://sqlite.org/forum/forumpost/c7f48602d4ce8dcb :
<<
- I listened to a talk by Richard Hipp the other day where he said varint was a mistake.
- Yeah, you did not get what he was saying about varints.  He only said that the SQLite3 implementation of varints was a mistake, because you need to parse the varint before you can compare it.  Just seconds later he proposes a different scheme (used in SQLite4, which experimental and has no release date) where the first byte tells you the length and magnitude of the varint so you can compare them with memcmp() without decoding the whole thing.
>>

TBD 24.08.24 what if like SDNV (RFC 6256) for very big lengths, retaining
memcmp()-sorting property? start with 0..143 to 60 above, then take CoAP
option length scheme may be used for low nibble, e.g. 0xF8..0xFC = 8..12 bytes
follows, 0xf0+13 = 1 byte (to 269) and 0xFE for 2 bytes (0xFF reserved? NaN?
Inf?), so 11110aaa ... for 7 bytes? Also it not quite good in that 128 bit
(IPv6) should be with just one byte overhead...
http://web.archive.org/web/20210128145701/http://www.dlugosz.com/ZIP2/VLI.html

 0..159
 101aaaaa bbbbbbbb                                     - 13
 1100aaaa bbbbbbbb cccccccc                            - 20
 1101aaaa bbbbbbbb cccccccc dddddddd                   - 28
 11100aaa bbbbbbbb cccccccc dddddddd eeeeeeee          - 35
 11101xxx aaaaaaaa bbbbbbbb cccccccc ...               - 40..96 bits
 11110xxx aaaaaaaa bbbbbbbb cccccccc ...               - 13..20 bytes
 11111yyy xxxxxxxx ...      aaaaaaaa ...               - to 2^64 bytes

 0..191
 110aaaaa bbbbbbbb                                     - 13
 11100aaa bbbbbbbb cccccccc                            - 19
 11101aaa bbbbbbbb cccccccc dddddddd                   - 27
 1111xxxx aaaaaaaa bbbbbbbb cccccccc dddddddd ...      - 32..120 bits
 111111yy xxxxxxxx ...      aaaaaaaa ...               - to 2^32 bytes
-- in 32 overhead is 1/4, too much

 0..191
 1100aaaa bbbbbbbb                                     - 12
 1101aaaa bbbbbbbb cccccccc                            - 20
 11100aaa bbbbbbbb cccccccc dddddddd                   - 27
 11101aaa bbbbbbbb cccccccc dddddddd eeeeeeee          - 35
 1111xxxx aaaaaaaa bbbbbbbb cccccccc dddddddd ...      - 40..128 bits
 111111yy xxxxxxxx ...      aaaaaaaa ...               - to 2^32 bytes

TBD 21.11.25 Note that above is for representing BigInts, but actual BigInt
format, especially with memcmp()-sortable property, will need more than that -
at least negative numbers, may be floating point. But if the need to encode
just *length* of some value, then actually we need less: given estimate of
about 10^80 order of magnitude atoms in Universe, no one will ever need more
than 2^264 bytes, so ASN.1 DER and MSDTP lengths of length up to 128 bytes are
too much; thus the task is effectively to create VarUInt256

 0..191
 110aaaaa bbbbbbbb                                                       - 13
 1110aaaa bbbbbbbb cccccccc                                              - 20
 110aaa bbbbbbbb cccccccc dddddddd                                     - 27
 111000aa bbbbbbbb cccccccc dddddddd eeeeeeee                            - 34

 11100100 aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee                   - 40
 11100101
 ...      26 lengths XXX not from 4?
 11111111 <32 bytes>

 0..143
 1001aaaa bbbbbbbb                                                       - 12
 1010aaaa bbbbbbbb cccccccc                                              - 20
 1011aaaa bbbbbbbb cccccccc dddddddd                                     - 28
 1100aaaa bbbbbbbb cccccccc dddddddd eeeeeeee                            - 36
 1101aaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff                   - 44
 111000aa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg          - 50
 11100101 aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg - 56
 ........
 11111111 - 33 bytes = 264 bits

 0..159
 1010aaaa bbbbbbbb                                                       - 12
 1011aaaa bbbbbbbb cccccccc                                              - 20
 1110aaaa bbbbbbbb cccccccc dddddddd                                     - 28
 1101aaaa bbbbbbbb cccccccc dddddddd eeeeeeee                            - 36
 111000aa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff                   - 42
 11100101 aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff          - 48
 ........
 11111111 - 32 bytes = 256 bits

Smart contracts use 256- or 257-bit integers; 256-bit words for the Ethereum Virtual Machine. "We realize that a 257 bits byte is quite unusual, but for smart contracts it is ok to have at least 256 bits numbers. The leading VM for smart contracts, Ethereum VM, introduced this practice and other blockchain VMs followed."[8]
[8]Borisenkov, Dmitriy (23 October 2019). "[llvm-dev] RFC: On non 8-bit bytes and the target for it". Retrieved 2021-09-11.<https://lists.llvm.org/pipermail/llvm-dev/2019-October/136115.html>

so it isn't clear if 256 or 264 bits better...

=========== Format with Sextets instead of VarNibbles =====

Pentads:

 0..15
 10aaa bbbbb                         - 8  | log2(1024)*3/4 = 7.5
 110aa bbbbb ccccc                   - 12 
 1110a bbbbb ccccc ddddd             - 16
 11110 bbbbb ccccc ddddd eeeee       - 20
 11111 bbbbb ccccc ddddd eeeee fffff - 25

 0..19
 101aa bbbbb                         - 7  | log2(1024)*3/4 = 7.5
 1100a bbbbb                         - +6 = 192 total, log2 ~= 7.58
 1101a bbbbb ccccc                   - 11 | log2(2^15)*3/4 = 11.25 ! too waste
 1110a bbbbb ccccc ddddd             - 16
 11110 bbbbb ccccc ddddd eeeee       - 20
 11111 bbbbb ccccc ddddd eeeee fffff - 25

VarSextet:

      0  
      0 1 2 3 4 5
     +-+-+-+-+-+-+
     |   0..47   | Integers from 0 to 47, themselves
     +-+-+-+-+-+-+

      0          |    
      0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 0 0| Biased Value  | Integer Values from 48 to 303  48 + 256 = 304
     +-+-+-+-+-+-+-+-+-+-+-+-+

      0          |        1  |
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 0 1|       Biased Value        | 304 ... 16687    304 + 2^14 = 16688
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0          |        1  |           |    2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 0| Value as is (for simplicity), 20 bits |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0          |        1  |           |    2      |
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1|       Value as is (for simplicity), 26 bits       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0..31
 10aaaa bbbbbb                             - 10
 110aaa bbbbbb cccccc                      - 15
 1110aa bbbbbb cccccc dddddd               - 20
 11110a bbbbbb cccccc dddddd eeeeee        - 25
 11111a bbbbbb cccccc dddddd eeeeee ffffff - 31

 0..31
 10aaaa bbbbbb                             - 10
 1100aa bbbbbb cccccc                      - 14
 1101aa bbbbbb cccccc dddddd               - 20
 1110aa bbbbbb cccccc dddddd eeeeee        - 26
 1111aa bbbbbb cccccc dddddd eeeeee ffffff - 32

 0..39
 101aaa bbbbbb                             -  9
 1100aa bbbbbb                             - +8 = 768 total
 1101aa bbbbbb cccccc                      - 14
 1110aa bbbbbb cccccc dddddd               - 20
 1111aa bbbbbb cccccc dddddd eeeeee        - 26

NB: encoded form must not occupt more than 32 bits, for 32-bit implementations!

 0..35
 1001aa bbbbbb cccccc dddddd eeeeee        - 26 in 30
 1010aa bbbbbb cccccc                      - 14
 1011aa bbbbbb cccccc dddddd               - 20 in 24
 11aaaa bbbbbb                             - 10 in 12


TODO

Appendix R.T. Research on Timestamps / TSN.

may-be goals - hierarchy of streams, get rid of non-aesthetic fragments
- 22.11.24 if we are comparing to ZFS then tree of streams is natural, may be
  even humanly *name* them?
  - the problem is, how to report such streams in API-s? it will typically be
    just 2 or 4 byte integer

* it could be made without TSN - observe we our ID is based on Timestamps
* also, the main reason for TSN to exist is for simple and compact SACK
* what if we could get rid of TSN completely?

"cumulative Timestamp" ? but we don't know how many were, this space is non-contiguous

no SACK at all, just ACK vectors (ECNE_CWR) ?
+ it's already has Packet Counter
+ count is per-packet, not per-chunk - longer wrap
- it is per-path

in any possible variant, still has a problem with Timestamp + PacketCounter:
what if in 1 or several ticks PacketCounter wrapped exactly at it size?
receiver at this packet do not know if packets with these ticks were lost or
just sender was quiet; this resembles same problem which FSN solves
-> have Pyramint5 for PkCntWrap: this PacketCounter_val was seen at least
   N time units ago
   -> requires 5 more bits, this could be solved by 1 flag bit and putting it
      into low bits of PacketCounter when they are zero, and require to always
      reply by ECNE_CWR on such numbers 
- TBD 23.08.25 holding array of counter size identificator may be expensive
  for implementation, what if in instead of PkCntWrap write just difference
  in time with previous packet? However, this will be problematic when two or
  more consecutive packets were lost after quiet time
  - is PkCntWrap needed at all? It's purpose is for ability to run-length
    compress Packet Vector by viewing it as continuous sequence from most
    recent packet back to past ignoring timestamp changes - but what if to
    just change compression method? On very small packets sizes there is no
    space for PkCntWrap anyway; also, do we really need to repeat DCCP and
    QUIC in that first is the most recent received packet?
    - 26.08.25 DCCP (in 4.2) states that due to unreliable semantics, there are
      "no retransmissions, and having a TCP-style cumulative acknowledgement
      field doesn't make sense" and thus "DCCP's Acknowledgement Number field
      equals the greatest sequence number received, rather than the smallest"
      sequence number not received.
PkCntWrap is not needed in black mode

seems that ECNE_CWR in this form is not needed - we already have SACK, so it
is for stats to cwnd adjust - whether was ECN, dups, etc.
* so we can go from exact per-packet to total counts per time interval
  - how wide be interval ? 1/8 second?
* still has problem with duplicates - what if attacker duplicates some to
  affect counters?
  - make Bitmap ranges specifically for duplicates?

for 999 high bits are larger than for 999999:
999999 = 11110100001000111111                         
   999 = 1111100111
- thus for ICMP either shift right, but this will look not correct
- or pass high bits, if we measure in tv_usec (hmm, this affects TIMESTAMP format)
-> differs in 5-th bit, that's probably where it's enough to cut

the counter in User Message ID must still be circular? as there can be paths with
different timestamp wide simultaneously
-> no, because if strict comparison of two IDs who is later, circular may
   wrap and later ID may become smaller
-> so, just make Message ID low 32 bits unique within a session (no streams
   ID), thus allowing even nanoseconds for systems wishing it, passing this
   frac always in header, and DUP will be NULL or time_t

in IMAP4:

   Example 1:  C: A142 SELECT INBOX
               S: * 172 EXISTS
               S: * 1 RECENT
               S: * OK [UNSEEN 12] Message 12 is first unseen
               S: * OK [UIDVALIDITY 3857529045] UIDs valid
               S: * OK [UIDNEXT 4392] Predicted next UID
               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
               S: A142 OK [READ-WRITE] SELECT completed

   Example 2:  C: A682 LIST "" *
               S: * LIST () "/" blurdybloop
               S: * LIST (\Noselect) "/" foo
               S: * LIST () "/" foo/bar
               S: A682 OK LIST completed

   Example 3:  C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
               S: * 2 FETCH ....
               S: * 3 FETCH ....
               S: * 4 FETCH ....
               S: A654 OK FETCH completed

for example, get a list of chat participants sorted by how recent online,
traditional pagination with offset and limit is subject to both:
1) list can change between next-bunch request, and
2) if DB, new OFFSET/LIMIT query can be heavy;
so it is possible to open low-priority message sequence in network and cursor in DB,
return one row per message and then receiver says "stop sequence" when it
feels enough
- but message sequence could be put in Presentation Layer attributes, so need
  nothing special for them in bit-format or QoS download continuation

for channels with extended data just use child channels, e.g. for 
SSH_EXTENDED_DATA_STDERR               1
will be first child; that's because they consume same window

AUTH does what's AH and ESP in IPSEC, if we want to application ability to
encrypt just some of data (streams), then may issue a different ConnectionTag
for it so have just like two paths in connection between the same addresses,
but with different tags
TBD why? just use Shared Key ID = 0

num of streams limited by kevent() - fflags and data should be treated as 32 bit
- moreover, if WSAAsyncSelect() then wParam is 16 bit and lParam is 32 bit
  TBD really? mingw has `typedef UINT_PTR WPARAM;` where `typedef unsigned int UINT_PTR`
- and Windows' MSG has no place for kevent.udata :(

still flat stream IDs - make tree like Btree in SQLite?

if TSN wraps about at the same time when SSN also wraps, then TSN can't be
used to disambiguate, and rule of 2^(N-1)-1 in flight still applies

TBD superseded by later message?

the reasons of SSN to exist is to:
* able to abandon blocks - just recv abandoned and be able to throw away
* size of message - if complete TSN wraps while on still one SSN:
  - 1 Gb msg limit prevents this, but then fragmentation comes into play
  -> must take to account in impl that (B) chunk could have gone away coz wrapped
if get rid of SSN, then abandoning must be on Time-based IDs - 8 bytes vs VarNibble,
and what to do with Unordered?

- 04.11.24 actually it's the opposite: TSN exists just for handy combined SACK,
  but conceptually (in ideal like TCP-3 Internet) there are many undirectional
  connections, like DCCP, VMTP [RFC 1045] or RDP [RFC 908]; and each can be
  divided into messages, and messages (e.g. up to 4 Gb) are having offsets to
  be fragmented by routers like in TCP-3 - now, we (and SCTP, and QUIC) combine
  all that streams into single association just for 2 purposes: mainly, common
  congestion control, and secondarily (as QUIC can't), multiple network paths,
  especially if simultaneously (each having it's own congestion control),
  reminding disks joined to zpool's and then divided to zfs filesystems. In
  such ideal Internet, these independent connections will still have
  independent numbering inside them, just getting help from network in form of
  some theoretical CCCP (Combined Congestion Control Protocol)...
  - 06.11.24 DCCP [RFC 4340] mentions RFC 3124 (Congestion Manager) with
    a seeds of similar idea, but that describes just needed API and never went
    to wire or newer/pluggable CC algorithms...
  - 30.11.24 Section 6.4.2 of RFC 9049 about trust model was different for
    ICMP Source Quench to work
  - 05.12.24 s/Combined/Centralized/, and as capitalism is over, RSVP/IntServ
    may be resurrected on new level (solving technical problems e.g. delay)

if SSN is to be replaced by just Time-based ID, then problem after with (B)
after silence - were there some intermediate messages or not? What if silence
has longed more than 32 bits allow and TSN wrapped - so always waste 7 bytes
in (B) for previous ID (except Unordered) ? bad for internal streams

idea: make "message ID" different per type: SSN for internal streams and
channels, Time-based for ordered/Unordered - so chunk parser must give both
"this and previous message ids" to TSN layer
-> not having SSN requires changes to message parts for ordered

what if have SSN/StreamID only in (B) ? e.g. in B=0 is always TSN Offset
instead of any headers; just may be of different size for int/user streams
- then no "two types", abandon is simple again
- StreamID may be useful for NAK when Window is full? TBD renege?

TSN Offset has problem: what if it is far past Cumulative TSN Ack? then need
to keep 65536 TSNs ?
- OK, let's return StreamID (so window NAK also possible), then keep one TSN
  per stream
- but that is only for ordered streams, what for Unordered - scan all SSN's?
- note that in theory, each SSN of Unordered is like child ordered stream
-> limit TSN Offset for Unordered to 1 byte ? then only 256 TSN's to keep
   TBD if keep 256 anyway, then save 1 byte for StreamID ?
-> or pass SSN for Unordered, unfortunately this is unavoidable

[consequencing thought by bird_of_Luck] what if untangle StreamID from actual
user API for letting protocol to decide where to put next message for HoL ?
e.g. we already have limited number of (de)compressors

RFC 1363 Flow token bucket

RFC 7228 Challenged networks
   [FALL]     Fall, K., "A Delay-Tolerant Network Architecture for
              Challenged Internets", SIGCOMM 2003, 2003.
   design cores for constrained devices.  While it is expected that the
   boundaries of these classes will move over time, Moore's law tends to
   be less effective in the embedded space than in personal computing
   devices: gains made available by increases in transistor count and
   density are more likely to be invested in reductions of cost and
   power requirements than into continual increases in computing power.

   Class 2 devices are less constrained and fundamentally capable of
   supporting most of the same protocol stacks as used on notebooks or
   servers.  However, even these devices can benefit from lightweight
   and energy-efficient protocols and from consuming less bandwidth.
   Furthermore, using fewer resources for networking leaves more
   resources available to applications.  Thus, using the protocol stacks
   defined for more constrained devices on Class 2 devices might reduce
   development costs and increase the interoperability.

   Constrained devices with capabilities significantly beyond Class 2
   devices exist.  They are less demanding from a standards development
   point of view as they can largely use existing protocols unchanged.
   The present document therefore does not make any attempt to define
   classes beyond Class 2.  These devices can still be constrained by a
   limited energy supply.


TODO tunnel backend type which is muSCTP itself - when client has no direct
muSCTP connection to server but intermediate machine can; full VPN (IP packets
in unordered messages) is overkill to implement here - just tunnel backend is enough
- also a mode when sockaddr is specially generated for client, so client will
  not know real server address
- such proxy could be implemented on small devices with no storage, e.g.
  OpenWRT
this to be called opaque proxy, in contrast to inspecting proxy

TODO sockaddr aliases - fot both NAT and NewIP segments TBD extension in tree

network.http.http3.default-max-stream-blocked is 20 in Firefox
nginx Default: 	http2_max_concurrent_streams 128;

TBD            RFC 7400           6LoWPAN-GHC

to minimize head-of-line blocking, scheduling of streams should be
proportional to cwnd
same applies to Pertial Reliability: "throwable" should not be bundled in one
TSN (packet) with really reliable chunks

TBD for XS pkt size when no MAC available, use scheme similar to  openssh's:
        uint32  checkint
        uint32  checkint
  but two bytes, where two 6-bit random fields must be equal (1/64 collision
  probability) and 4 bit is for checksum of first 20 bytes (TBD how many?)
  which is 1/16 collision probability, giving 1/1024 total - more than that
  of 1/256 of just two equal bytes
  TBD or be it 2 nibbles and 1 byte of in_cksum()-like, so 1/4096 total? 

TBD there is problem with child stream ordering for e.g. stderr on SSH ?
e.g. if we put SSH_MSG_CHANNEL_EXTENDED_DATA into child stream and packet
loss occurs, user will see stdout & stderr in different order
TBD but is it critical ?

If a client makes concurrent requests with the incremental parameter set to false, there is no benefit in serving responses with the same urgency concurrently because the client is not going to process those responses incrementally. Serving non-incremental responses with the same urgency one by one, in the order in which those requests were generated, is considered to be the best strategy.

HTTP ecosystem problem:
   It is designed to encourage faithful implementation and good
   interoperability.  Therefore, an implementation that tried to be
   helpful by being more tolerant of input would make interoperability
   worse, since that would create pressure on other implementations to
   implement similar (but likely subtly different) workarounds.
...
   To further assure that this extensibility is available in the future,
   and to encourage consumers to use a complete parser implementation, a
   field definition can specify that "grease" parameters be added by
   senders.  A specification could stipulate that all parameters that
   fit a defined pattern are reserved for this use and then encourage
   them to be sent on some portion of requests.  This helps to
   discourage recipients from writing a parser that does not account for
   Parameters.

what the shit is HTTP/2:
   Each header block is processed as a discrete unit.  Header blocks
   MUST be transmitted as a contiguous sequence of frames, with no
  interleaved frames of any other type *or from any other stream*.


crazy idea of splitting TSN to Block number + Offset or Length Left:
+ no limit to header now, even Chunk Type could be wide and once
+ 2^31 TSN in flight + 2^13 of block - match to max window size
+ no separate frag opt, natural way for routers to frag as in TCP v3 [IEN21]
* split it separate layer, for routers and to have entire packet, not only TSN,
  also for AUTH - coz when single frag ?
- what will router do with Packet Counter for new frags?
- it any way, it becomes per-path
- if TSN, block size is limited so need to convert internal streams to blocks, too
- big problem: how to SACK now? put offsets to packet vector? but it's limited
: note that SACK unit must be per-packet or less - due to NAK possibility, and NAK is
  due to stream windows and compression
TBD somewhat possible if in SACK:
       0                    0                     0               
change 0 1 2 3 4 5 6 7  to  0 1 2 3 4 5 6 7  and  0 1 2 3 4 5 6 7    
      +-+-+-+-+-+-+-+-+    +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+ 
      |0|   Bitmap    |    |0 0|  Bitmap   |     |0 1|F|  Count  | 
      +-+-+-+-+-+-+-+-+    +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+ 
where F="first received", so when F=0 then Count is Pyramint5 "approx total bytes recv so far"
and when F=1 then Count is "cumul fragment ack" in 1/32-ths of known chunk size
- this is too small, cumul ack should be exact or else how to distinguish?
- if divide pages into paragraphs (like SCHC tiles), then possible... allow page size 1K or more for hdr?
- do it in SACK like BSD UFS/FFS block/fragment division?
- still same problem: what if for 640 byte chunk tile is 10 b and MSS 39 b ? waste of space/pkt/time
4 3 2 1 0 : in 3 bits, 5 frags could be described: last can't be first and
  * * *     in max fize first is always first, no need spend val on it
moreover, if pass length in first frag anyway, then "first" could be one of
values instead of wasting bit
- N + N/4 for 2 bits of first and 14 bits of length
- need frag number in NAK also?

TBD study "Rapid Reset" HTTP/2 attack, invent countermeasures if applicable to us
- 14.08.25 "MadeYouReset" attack is again consequence of architecture flaw of
  stream per request instead of constantly-open streams

TBD 29.06.25 load balancers: round-robin is bad for TCP performance, make us
somehow resilient to misordered packets; another UDP port for each stream: is
it good or bad idea?
- 16:15 for UDP ports seems idea bad
- 19:45 try rule: when gap, if highest recvd TSN is not an End chunk, delay SACK
  reply by RTTvar of peer
  - 25.07.25 08:45 need to include ACK delay field

TBD 02.11.25 like original ARPAnet motivation, need a kind of nodes which are
for connectivity only (not data/API), so that destroying such node does not
mean destroying real ThS node (case of user-spy/enemy), probably even two-level
(like Tor) - so need to determine if our proxy functionality is enough or need
to add something more for this "front-back" analogy to protocol

TBD 20.02.26 give applications access to selecting tunnels, e.g. very slow vs very fast for different needs, may be OSPF 16 bits of bandwidth here?

TBD 18.06.26 HTTP method QUERY: В методе QUERY предусмотрена поддержка кэширования - прокси-серверы или обработчики могут сохранить результат выполнения запроса, присвоить ему URI для последующего обращения через метод GET и вернуть информацию о выдаче прокэшированной версии через заголовок "Last-Modified". Для проверки наличия изменений с прошлого запроса может применяться заголовок "If-Modified-Since". Для указания альтернативных вариантов выполнения запроса в ответе могут указываться заголовки "Content-Location" и "Location", отличия которых в том, что первый передаёт ссылку для получения результата ранее выполненного запроса, а второй предназначен для повторения запроса с теми же параметрами. 


TODO