Re: Idea for packet numbers

[Dmitri Tikhonov <[e-mail]>]

On Tue, Jul 25, 2017 at 10:04:52AM +0000, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote:
> From the senders perspective the process it goes through is:
> 1. Get data to send
> 2. Get packet number
> 3. encrypt packet
> 4. queue packet on NIC
> 5. NIC sends packet.

I think this model needs to account for the OS.

A normal application does not write to NIC directly: it goes through
the kernel.  A socket's send buffer may get full and queueing a packet
may fail.  Let's assume that happens and the application waits to queue
a packet.  (If instead you just throw this packet out and pretend that
you queued it, then it is conceptually the same as the "write to NIC
directly" model above, but I don't think many people are ready to take
that route.)  While the application waits for the socket to become
writeable, an ACK alarm may go off or new packets may arrive for this
connection: generating and sending an ACK is in order.  Since we want
to send the ACK first, the buffered, not-yet-sent packet may need to be
renumbered, have its contents changed, or both:

    - Either the packet does not contain an ACK, in which case the
      new ACK frame is put into a new packet and the buffered packet
      gets a new packet number; or
    - The packet contains an ACK which can be replaced with the new
      ACK (if there is room), in which case the packet gets to keep
      the number, but the packet contents change.

Another scenario where butchering unsent packets is required is when
RST_STREAM comes in: application must then drop outgoing STREAM frames
for that stream.

The process is, then:

    1. Get data to send
    2. Get packet number
    3. Encrypt packet
    4. Try enqueuing packet
        a) If successful, "commit" packet number and go to (1)
        b) If unsuccessful, wait and do something smart later,
           depending on circumstances

Just my $.02,

  - Dmitri.