Subject: [hybi] request for a consensus call on length encoding

From: John Tamplin <[email-masked]>
Date: Tue, 24 Aug 2010 18:14:54 -0400

We have debated and debated, and a number of good options have been
proposed.  At this point, it seems unlikely that we are going to get any new
information as to the relative merits of the various proposals, and I think
there is little to separate many of the choices - they primarily differ in
how they might serve future frame size distributions or needs for reserved
bits, which are hard to quantify.

So, I would like to suggest that the WG chair select one of the proposals
with good support and see if we can declare consensus on it.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Brian <[email-masked]>
Date: Tue, 24 Aug 2010 15:21:56 -0700

+1!

Use a dart-board if necessary.  I don't care which proposal we choose at
this point.  I'll support whichever option the chair suggests.  :-)

Brian

On Tue, Aug 24, 2010 at 3:14 PM, John Tamplin <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 24 Aug 2010 17:52:55 -0500

John Tamplin wrote:
>  At this point, it seems unlikely that we are going to get any new
> information as to the relative merits of the various proposals,
> and I think there is little to separate many of the choices - they
> primarily differ in how they might serve future frame size
> distributions or needs for reserved bits, which are hard to quantify.
> 
> So, I would like to suggest that the WG chair select one of the
> proposals with good support and see if we can declare consensus
> on it.

My suggestion is to suspend the length encoding debate until the group agrees to stop adding new features that would affect the frame header. In the interim, just use the length encoding that's in the draft right now, with the understanding that it is going to change later. Finalizing the frame length encoding now and then adding new fields to the frame header afterward is virtually guaranteed to result in a sub-optimal encoding.

ROHC (RFC5795) compresses the entire TCP/IP header down to a couple of bytes. And, even the simple encoding I suggested is able to combine the frame type field and the frame length into a single byte for the most common frame type and frame sizes up to 372 bytes. (That encoding can probably be extended to encode even some flags into that single byte for frame sizes that are critical to power-conscious mobile applications). It isn't possible to create optimal encodings using these kinds of techniques until more information about the contents of the frame header are known.

So, +1 for ending (suspending) the debate now,  but -1 for finalizing things now.

Regards,
Brian

---

From: John Tamplin <[email-masked]>
Date: Tue, 24 Aug 2010 19:29:17 -0400

On Tue, Aug 24, 2010 at 6:52 PM, Brian Smith <[email-masked]> wrote:

> My suggestion is to suspend the length encoding debate until the group
> agrees to stop adding new features that would affect the frame header. In
> the interim, just use the length encoding that's in the draft right now,
> with the understanding that it is going to change later. Finalizing the
> frame length encoding now and then adding new fields to the frame header
> afterward is virtually guaranteed to result in a sub-optimal encoding.
>

I believe the proposals have sufficient extensibility that it won't be a
problem.  Even so, if during those discussions we determine that we need to
change the header we can, as long as we do it before finishing the entire
base spec.

> And, even the simple encoding I suggested is able to combine the frame type
> field and the frame length into a single byte for the most common frame type
> and frame sizes up to 372 bytes.

The problem with that encoding is that people were complaining about the
complexity of the 7/16/63 option, so my personal feeling is that a proposal
that can't be clearly explained in a couple of sentences is likely to gain
consensus.  I really don't think the efficiency differences between any of
the proposals that have any support is enough to worry about.

> It isn't possible to create optimal encodings using these kinds of
> techniques until more information about the contents of the frame header are
> known.
>

Before we stopped trying to limit discussions to the base protocol framing
and declare extensions as external to that, we were in a never-ending cycle
of discussing extension ideas and others saying such extensions were too
complicated for the base protocol and we were making no progress.  I think
the way forward is to nail down (with the understanding that if we later
determine it was a mistake we can revisit it) the base framing and say that
compliant implementations don't have to worry about anything beyond that,
then move to a discussion about specific extensions which various people
believe are important.  I believe the current framing proposal
will accommodate all the various extension mechanisms that have been
discussed, and those that think the extensions aren't warranted won't be
bothered by the discussion because they know they can ignore them if they
want.

Since that path was started, we went from not getting agreement on much of
anything to agreeing on basically everything about the framing except how
the length is encoded in the header, which I think is great progress.

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 24 Aug 2010 17:24:05 -0700

Brian wrote:
> +1!
>
> Use a dart-board if necessary.  I don't care which proposal we choose 
> at this point.  I'll support whichever option the chair suggests.  :-)

+1

Both of the top two 1/2/8 proposals are good. I'd support either one.

-- Scott

>
> Brian
>
>
> On Tue, Aug 24, 2010 at 3:14 PM, John Tamplin <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     We have debated and debated, and a number of good options have
>     been proposed.  At this point, it seems unlikely that we are going
>     to get any new information as to the relative merits of the
>     various proposals, and I think there is little to separate many of
>     the choices - they primarily differ in how they might serve future
>     frame size distributions or needs for reserved bits, which are
>     hard to quantify.
>
>     proposals with good support and see if we can declare consensus on it.
>
>     -- 
>     John A. Tamplin
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 24 Aug 2010 19:52:07 -0700

Ditto.
Once we decide on variable-size headers, it really doesn't matter which of
these we pick to me. Moving forward is more important.
-=R

On Tue, Aug 24, 2010 at 5:24 PM, Scott Ferguson <[email-masked]> wrote:

>> On Tue, Aug 24, 2010 at 3:14 PM, John Tamplin <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>    --     John A. Tamplin

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 25 Aug 2010 07:21:15 -0400

I wish to unsubscribe from this list. List members, please kindly do not
copy me on any email that you are also sending to the list, so that I am
not tempted nor accidentally reply all to the list. The Chair knows where
to reach me, if the list needs my technical input.

I think I have made all my technical points.

My suggestion is to declaring the necessary elements of the header,
declaring the framing layer correctly, and enumerate the various length
encoding options for now. You can temporarily use 2 of the extension bits
to declare the chosen length encoding.  So this way implementators can get
experience with all the encoding options and give feedback to this list.

Please read these relevant posts:

http://www.ietf.org/mail-archive/web/hybi/current/msg03687.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03685.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03686.html

I believe in free markets and competition. Communists (people who resist
free markets) are the scum of the earth. People who judge each other, will
be judged the same (Matthew 7, Jesus)-- a big mess of intertwinded
failure.