Subject: [hybi] yet another framing proposal (only a slight twist on the current one)

From: Brodie Thiesfield <[email-masked]>
Date: Tue, 31 Aug 2010 07:38:24 +0900

Hi,

I've been watching the current discussion on framing, and
there appears to be a strong desire to minimize the frame
size for use with FACH on mobile data networks. My use-case
will have huge frames so this is not an issue for me.

However for those that are interested, the following simple
rearrangement of the current frame structure results in
potential savings of 1 byte per frame for messages
fragmented into small simple frames with >2 fragments.

There is no change in size from the current proposal for
messages of 1 or 2 fragments. The penalty is the loss of
the RSV2 bit from the current proposal.

This method also allows an intermediary to split a message
into arbitrary simple fragments without examining the
contents, or to join back together simple fragments.

Frame:
+---------+-----------+
|  1 bit  |   7 bits  |
| USEHEAD | SHORT-LEN |
+---------+-----------+
|    0/2/8 bytes      |
|      LONG-LEN       |
+---------------------+
|      0-x bytes      |
|       HEADER        |
+---------------------+
|      0-y bytes      |
|       PAYLOAD       |
+---------------------+

USEHEAD = (was RSV2)
    if 1 then this frame contains a HEADER byte and
    should be examined for pertinant info (e.g. muxing).
    If 0 then no HEADER exists and it is a simple
    payload data fragment.

SHORT-LEN = 0-125=actual, 126=+2 bytes, 127=+8 bytes

LONG-LEN = exists only when SHORT-LEN is 126 or 127

LENGTH is for complete payload (HEADER + PAYLOAD)

HEADER = only exists if USEHEAD bit is 1. See the
    current proposal for full spec of opcode,
    reserved bits, extension data, etc. Only change
    is that the MORE bit becomes a LAST bit and the
    CONTINUATION opcode becomes a LAST opcode.

     0 1 2 3 4 5 6 7
    +-+-----+-------+
    |L|  R  | Opcode|  LAST   = 1 bit
    |A|  S  |       |  RSV    = 3 bits reserved
    |S|  V  |       |  OPCODE = 4 bits
    |T|     |       |
    +-+-----+-------+

    LAST is a flag bit used to mark the last frame in
    the message. An OPCODE of LAST (0x00, replacing the
    existing CONTINUATION opcode) is used for the last
    frame in a fragmented message. Any other valid
    opcode is used for a single fragment message.

PAYLOAD is binary data.

This message format re-orders the frame layout to permit the
HEADER byte(s) to be dropped for simple continuation fragments.
First and last packets in a fragmented message use USEHEAD=1
and specify in the header if they are the first or last fragment.

This format produces frames with the same size as the current
proposal for messages in 1-2 fragments, and may save 1 byte
per fragment at all other times if simple continuation frames
are used. It is no larger than the current proposal.

Note that if any extension data is necessary in fragments (e.g.
for mux) then the USEHEAD=1 is necessary and again the size
is no different from the current proposal.

An intermediary could split a single fragment into multiple
fragments by splitting a fragment anywhere after the HEAD byte
and sending the remainder with the USEHEAD bit unset. It doesn't
need to worry about extensions at all (unless required by spec)
Of course, the end user of the messages would need to be aware
of this type of fragmentation.

Multiple fragments without the USEHEAD bit set (simple fragments)
can be simply concatenated to reform a larger fragment.

Note that extensions and opcodes etc are TBD as per the current
proposal.

Frame types:
    No fragments, first and last frame:
        USEHEAD=1, LAST=1, OPCODE!=0
    Fragmented, first frame:
        USEHEAD=1, LAST=0, OPCODE!=0
    Fragmented, last frame:
        USEHEAD=1, LAST=1, OPCODE=0
    Fragmented, simple data frame (not first or last):
        USEHEAD=0
    Fragmented, data frame with header (e.g. mux info):
        USEHEAD=1, LAST=0, OPCODE!=0
        Note: this frame type is same as fragmented/first.
        If differentiation is required, it must be via the
        opcode or using RSV for a FIRST flag.

Example: Not fragmented

    0x8d 0x84 "Hello World!"
     (USEHEAD=1, SIZE=13, LAST=1, OPCODE=4)

Example: Fragmented into 2

    0x87 0x04 "Hello " (USEHEAD=1, SIZE=7, LAST=0, OPCODE=4)
    0x87 0x80 "World!" (USEHEAD=1, SIZE=7, LAST=1, OPCODE=0)

Example: Fragmented into 4

    0x85 0x04 "Hell"  (USEHEAD=1, SIZE=5, LAST=0, OPCODE=4)
    0x02      "o "    (USEHEAD=0, SIZE=2)
    0x02      "Wo"    (USEHEAD=0, SIZE=2)
    0x85 0x80 "rld!"  (USEHEAD=1, SIZE=5, LAST=1, OPCODE=0)

Example: Fragmented with empty last frame

    0x87 0x04 "Hello " (USEHEAD=1, SIZE=7, LAST=0, OPCODE=4)
    0x06      "World!" (USEHEAD=0, SIZE=6)
    0x81 0x80          (USEHEAD=1, SIZE=1, LAST=1, OPCODE=0)

Regards,
Brodie

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 30 Aug 2010 15:53:11 -0700

As an individual:

Brodie,

My thoughts are generally that this adds a fair deal of complexity without
really that much benefit. Yes, it can save a byte on some frames, but
consider:

1. The first frame still needs the header (to indicate opcode etc).
2. The last frame in your proposal still needs the header (to indicate
"LAST")
3. The only messages that will benefit are those that are sent with 3+
fragments, at which point the 1 byte overhead becomes less compelling IMO.

Personally, I'm a bit freaked out about intermediaries re-fragmenting
messages, so I'm not super excited about trying to explicitly support this
use case. Without going down the rathole of defining extensions right now,
there have been extensions discussed that are relevant to the *data* and
some that are relevant to the *frame*, and the latter seem complex in the
face of intermediaries that re-fragment. As such, saving 1 byte/fragment on
messages with >= 3 fragments just doesn't seem worth it. At this point, I
would much rather try to resolve open issues with the last proposal (VII)
rather than continual new proposals (speaking as an individual).

-Ian

On Mon, Aug 30, 2010 at 3:38 PM, Brodie Thiesfield <[email-masked]>wrote:

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