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

[Patrick McManus <[e-mail]>]

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.

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

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.

-Patrick