Say, why not keep the multicastSymbol and the 3byte msgSpec, with 4 6bit fields. Keep the size field at 4bytes. This is 7bytes and will fit a 64bit register with a little headroom, if it's an immediate value or wahtever is done.

---
Free association thinking about FEC specification follows...

Lookingi nto the FEEC header it is 5 bytes, but that's too big!!  Not needed! How about 2bytes blockCount?

With RS(255,223), the current largest, and 2 bytes of blockCount, with 4 RS chunks per block, that's 1020bytes encoded per block (892bytes data)...munch, munch, munch...67MB of FEC coded size or 58MB data per message. This seems reasonable to restrict it to this size. If you've more then your app better be fragmenting its communications in healthy sized chunks...least that's how I'm thinking about it.

Alright then, lets try to fit the msgSpec and the FECSpec into 1 dedicated 64bit register, maybe no tags....rsCode values can be restricted to 4, so 2bits. 10bits for blockCount = 1 MB FEC encoded/913 KB raw. Is that reasonable to limit it so and require higher fragmentation?? That would be a session layer activity.  Well, that's 12 bits. If we knock sanguinity back to 2 bits (FLASH, IMMEDIATE, PRIORITY, ROUTINE), that's 32bits with a max of 1MB specified. 20bit size would do it, leaving 12bits of tag space, perhaps the primary polynomial coefficients could go there, with room to spare.

This means the msgSpec layout for FEX enabled comms is different than for all other messages not error correction encoded.

---Default non-FEC msgSpec + header + payload layout:

- 6bits multicastSymbol
- 2bits sanguinity
- 6bits messageVersion
- 6bits headerType "NOTE: except for FEC encodings"
- 4bytes messageSize
- Xbytes header
-
- (messageSized - headerSize - 7specBytes) Bytes-sized payload


Special FEC coded 64bit <msgSpec + header> + payload layout, for 64bit alignment:

- (32bits...)
- 6bits multicastSymbol
- 2bits sanguinity
- 6bits messageVersion
- 6bits FEC message type "NOTE: this means different layout"
- 2bits rsMode
- (32bits...)
- 10bits blockCount           "NOTE: for 1MB encoded/982KB data"
- 20bits messageSize        "NOTE: this can specify 1MB data plus
- 8bits primitivePolynomial spec (good for our current rsModes)
- 4bits tagging
-
- (messageSized - headerSize - 4specBytes) OR (blockCount * rsMode's blockCodeBytes) Bytes-sized payload


Is this complexity desired, I would ask you? If it is, is this the right layout?

thank you,
robert


On 12/20/2015 09:48 AM, Robert Withers wrote:
To sort of summarize, then, with this msgSpec, including overall size, structure and priority (1 / sanguinity) specified in 6 or 7 bytes, will fit a 64bit register, with room, for low-level routing. Add a 32bit register to the 64bit register, and you can fit the 11 or 12 bytes to fully specify the FEC encoding, for hardware assisted en/de/coding. I thought this may be important. On the right track?

thanks ,
robert

On 12/20/2015 09:33 AM, Robert Withers wrote:
Ok, let me make one last change to this 7 byte alternate proposal for the message specification. In the first 3 bytes with 4 fields, use supersymmetry to specify 6bits per field. SO the alternate would look like below...

The whole point of the multicast symbol is to provide for low-level routers to not even have to decode the asn.1 header and distinguish all our message and header types. Just grab the first byte and mask the upper 6bits and shift, there is a destination specifier, at least in the large, as an alternate tunneling capability and would support reuse of 4byte IP addresses for NAT.  If we loose that and knock sanguinity back to 2bits, then we are down to a 6 byte spec + payload.  I'm mulling iot over, obviously.

msgSpec: 7 bytes binary encoded


--
. .. .. ^,^ robert

--
. .. .. ^,^ robert

--
. .. .. ^,^ robert