Re: Idea for packet numbers

[Dmitri Tikhonov <[e-mail]>]

On Wed, Jul 26, 2017 at 09:27:19AM +0000, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote:
> > > to do that would be to give the ack packet a higher packet number but
> > > then send it before lower marked packets - even potentially if they do
> > > also contain ack frames.
> > 
> > That is a good approach if it does not break packet number derivation.
> > I am not sure whether it can...  The draft says:
> > 
> >   " A packet number is decoded by finding the packet number
> >   " value that is closest to the next expected packet.
> > 
> > Thus, after receiving ACK packet with large gap, which is the next expected
> > packet number from the point of view of the peer?
>
> The spec says that you should give plenty of room in the number space,
> so as long as you haven't reached half your number space across that
> period this should be extremely rare or perhaps impossible.  The worst
> case is that if you do violate it then either you may be requested to
> retransmit some packets, or you just send the original packets first
> and then the ack.

OK -- this should work.  I'd have to work out the math to prove it to
myself, though. :)

> > > For RST_STREAM I think it is permitted that currently queued packets
> > > are still sent, but if they only contain that streams packets then it
> > > is a beneficial optimization if they weren't sent (leaving packet
> > > number gaps).
> > 
> > Current draft says:
> > 
> >   " An endpoint that receives a RST_STREAM frame (and which
> >   " has not sent a FIN or a RST_STREAM) MUST immediately
> >   " respond with a RST_STREAM frame, and MUST NOT send any
> >   " more data on the stream.
> > 
> > I suppose one could interpret "send" to mean "enqueue," but I would err on
> > the side of caution.
>
> With a basic integration between an application and quic stack the
> api would likely just be the application writing a load of data onto
> a stream which then gets multiplexed into a quic connection.  In this
> case the application view would be once it has written it to the
> stream it is being 'sent' - in the same way the assumption is held for
> TCP transmission.  Packetization and enqueuing for transmission would
> therefore be considered part of the sending process and with that API
> it would seem to be fair to send queued data but not allow new writes
> from the application.

Sure, I agree -- I was not talking about the application level at all,
just the QUIC layer.  The application should not be in the business of
sending RST_STREAM frames.

> Assuming no re-encryption/packetization, that is pretty much all you
> can do if packets contain data from multiple stream frames anyway.

If one assumes that, then yes.

> The "immediately respond with a RST_STREAM" perhaps then needs to be
> read as: "immediately, after any pending packets have been transmitted,
> such that no new packets with data from that stream are generated with
> a higher packet number than the RST_STREAM response frame."?

Not unless the "MUST NOT" in the quoted draft paragraph above be changed
to "SHOULD NOT:"  An eager implementation may check whether its peer has
sent stream data after receiving RST_STREAM (which it would know by the]
ACK frame) and terminate the connection.

  - Dmitri.