Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order

[Jana Iyengar <[e-mail]>]

Hi Patrick,

On Fri, Nov 4, 2016 at 2:01 PM, Patrick McManus <[e-mail]>
wrote:

> Hi All - two more things to raise.. one I hope editorial and one design -
> when we start doing github, I'll open issues to track there.
>
> First, editorially draft-hamilton-quic-transport-protocol-01 generally
> refers to packet numbers instead of sequence numbers. There seem to be two
> exceptions to that - in 6.2 and the identifier
> SEQUENCE_NUMBER_LIMIT_REACHED. OTOH https://tools.ietf.org/html/
> draft-thomson-quic-tls-01 almost always refers to sequence numbers (with
> one exception). I think SN is not defined, but PN is and it should
> standardize on the PN language.
>

This should all be Packet Number, and we should fix it all. The history is
that we used to call these Sequence Numbers, until we decided that the
overlap with TCP terminology was unnecessarily confusing, since there are
clear semantic differences between sequence number in TCP and packet number
in QUIC. (Specifically, sequencing is used in TCP to order received bytes
at the receiver, whereas Sequence Numbers in QUIC have only to do with the
order in which packets may have been sent. There's also freedom at a sender
to skip some numbers while sending, to avoid optimistic ack attacks, which
means that packets sent in sequence may have discontiguous numbers
assigned.)


> Second, draft-hamilton-quic-transport-protocol-01 boldly uses little
> endian encoding. Ya gotta admire that chutzpah in an IETF draft :)
>

More chutzpah than redefining HTTP transport with a 3-part non-layered
protocol at the IETF? :-)

>From a processor alignment pov, it makes perfect sense and I would support
> it on a clean slate or on a well layered protocol. quic however, by design,
> is neither of those things.
>

(I now proceed into this bikeshed. It was good to know you all.)
I think disagree. I definitely think we have a clean-slate, at least as far
as *this* protocol is concerned (modulo the running code.) I would argue
that we have a well-layered protocol, but it is not "simply-layered". See
more below.

So we get into a bit of a mess - the packet number is little endian when it
> appears in transport fields, but in the TLS document the AEAD nonce is
> formed by padding the big endian representation of the same number. That
> smells like a bug waiting to happen. Likewise a Stream ID in a transport
> STREAM frame would be big endian, but when that same ID is encoded via 7540
> rules from the h2-mapping document (e.g. in a PUSH_PROMISE) then it needs
> to be big endian. Again - seems like a footgun. So while I salute the
> valiant effort to go little endian, I think we ought to bow to the
> constraints this effort faces and go the traditional all network byte order
> path.
>

So, to be clear, as long as the QUIC framer (as against the TLS or the HTTP
framer) is the thing that's writing numbers on one side, and the QUIC
framer is the thing reading numbers on the other side, there's no issue
with endianness. In addition, if it's a non-QUIC framer writing numbers on
one side, and a non-QUIC framer reading numbers on the other side, QUIC
doesn't introduce any issues with endianness.
On how the bits are used by other components which interact with the QUIC
framer, that's a matter of API.

So, if the TLS nonce is sent and delivered over Stream 1. QUIC transports
and delivers bytes over Stream 1. QUIC doesn't care about the endianness of
the nonce just as the nonce's endianness would have nothing to do with
TCP's rules about endianness in TCP fields.

Similarly,  a Stream ID in a PUSH_PROMISE frame, which is sent as an H2
frame is basically opaque data on the wire to QUIC. In the mapping doc, a
PUSH_PROMISE frame is sent over the Headers stream, which is entirely an
HTTP-mapping concept. From QUIC's pov, it's a stream as any other. When an
HTTP client receives this frame over QUIC, it will probably "reserve" this
stream ID through an API call down into QUIC.

So yes, while not simply-layered, there's very clear encapsulation and
separation of functions and concerns. Non-QUIC entities MUST NOT put things
in the QUIC frame format, and MUST NOT read things directly from the frame
format.

That said, I understand that there's baggage in terms of what the IETF has
always done. The argument against it is that when engineering for the
common case, little endian makes much more sense in today's world.

(ducking for cover)
- jana


>
> -Patrick
>
>
>
>