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

[Brian Trammell <[e-mail]>]

hi Patrick, all,

> On 04 Nov 2016, at 22:01, 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.
> 
> 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.

Either +1 or [phone] to this, depending on your native byte order.

Even without the interactions with TLS and H2, a QUIC header merged with a UDP header would have two byte orders (big in the ports and length, little everywhere else).

The currently dominant processor architectures may be little-endian (though, given that the byte-order conversion calls pretty much always operate on cache, they're basically free) but we've spent decades training everyone that the network is big endian, and this decision itself also has a rationale grounded in transparency and diagnosability for humans looking at packet dumps: most of our notations for dealing with numbers are big-endian. So going little-endian seems like an esoteric choice with a whole lot more downside than upside.

Cheers,

Brian