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

[Martin Thomson <[e-mail]>]

I'm going to recommend that the big-endian and little-endian
proponents find themselves a room in Seoul.  I plan to mute any thread
that continues in this fashion.  It's not a rathole, it's the Sarlacc.

On 8 November 2016 at 10:30, Jana Iyengar <[e-mail]> wrote:
> 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
>>
>>
>>
>