IETF Logo Mail Archive

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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sat, 05 November 2016 08:57 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8574129407 for <quic@ietfa.amsl.com>; Sat, 5 Nov 2016 01:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Level:
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58YcqnpgqrsX for <quic@ietfa.amsl.com>; Sat, 5 Nov 2016 01:57:49 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC2A1293E8 for <quic@ietf.org>; Sat, 5 Nov 2016 01:57:48 -0700 (PDT)
Received: from [192.168.1.101] (p508F1FF0.dip0.t-ipconnect.de [80.143.31.240]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7FC98721E281E; Sat, 5 Nov 2016 09:57:41 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <08188AC9-60C7-4E71-AE01-54D9FD487918@netapp.com>
Date: Sat, 05 Nov 2016 09:57:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8394F94-1A76-40F6-98F7-3EFBE732AC46@lurchi.franken.de>
References: <CAOdDvNo_WjE-39uWm49aFH-_TCeaKdik2hsGbSduhowtKqNHqQ@mail.gmail.com> <08188AC9-60C7-4E71-AE01-54D9FD487918@netapp.com>
To: "Eggert, Lars" <lars@netapp.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HMyJ0-xauuGoojmfIpb3NoTBFAc>
Cc: "quic@ietf.org" <quic@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Nov 2016 08:57:51 -0000

> On 5 Nov 2016, at 09:09, Eggert, Lars <lars@netapp.com> wrote:
> 
> On 2016-11-04, at 22:01, Patrick McManus <pmcmanus@mozilla.com> wrote:
>> 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.
> 
> Chair hat off: That totally threw me when I started to implement, because apparently my mind is trained to automatically insert htonl() etc., and it took me a minute or so to understand why my code was producing incorrectly laid out packets.
I guess if you really want to write a portable implementation you need to insert functions,
just not hton[sl](). You need to write htole[sl] and use them...

Best regards
Michael
> 
> Lars

v2.23.0 | Report a Bug | By Email