[Vm-dev] Re: SecureSession frame types

[Robert Withers]

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*
>>
>>   * HeaderSpecification: 3 bytes
>>       o multicastSymbol: 6 bits
>>       o sanguinity: 6 bits
>>       o msgVersion: 6 bits
>>       o hdrType: 6 bits
>>   * msgSize: 2nd word, 4 bytes
>>       o 4 bytes (total size with msgSpec, header, payload sizes)
>>
>>
>>
>> -- 
>> . .. .. ^,^ robert
>
> -- 
> . .. .. ^,^ robert

-- 
. .. .. ^,^ robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151220/35bfaf62/attachment.htm