I wrote up the various SecureSession frame types in presentation document, which you can get here: https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0
These are not yet implemented, but it is progressing. Ne quid nemis.
thanks,
Excuse me for failing to complete this email./ I wanted to ask for feedback on these structures, especially the header specification word structure. So these fields make sense?
thank you, robert
On 12/20/2015 05:27 AM, Robert Withers wrote:
I wrote up the various SecureSession frame types in presentation document, which you can get here: https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0
These are not yet implemented, but it is progressing. Ne quid nemis.
thanks,
Irked and confused how to share updatable documents through dropbox. It didn't help that I had logged off the daemon. I reordered the 64bit header. Here's an updated link. If the doc changes in the future, I hope this link continues to work.
https://www.dropbox.com/s/zj2i1votg432b2p/FrameTypes.pptx?dl=0
regards, robert
On 12/20/2015 05:31 AM, Robert Withers wrote:
Excuse me for failing to complete this email./ I wanted to ask for feedback on these structures, especially the header specification word structure. So these fields make sense?
thank you, robert
On 12/20/2015 05:27 AM, Robert Withers wrote:
I wrote up the various SecureSession frame types in presentation document, which you can get here: https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0
These are not yet implemented, but it is progressing. Ne quid nemis.
thanks,
Hello,
I tried to get your document but I got:
Dropbox - error
Is it only me ?
2015-12-20 11:31 GMT+01:00 Robert Withers robert.w.withers@gmail.com:
Excuse me for failing to complete this email./ I wanted to ask for feedback on these structures, especially the header specification word structure. So these fields make sense?
thank you, robert
On 12/20/2015 05:27 AM, Robert Withers wrote:
I wrote up the various SecureSession frame types in presentation document, which you can get here: https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0
These are not yet implemented, but it is progressing. Ne quid nemis.
thanks,
-- . .. .. ^,^ robert
Sorry about that Clément, I updated the doc and lost the link. I have insured that I can now update the doc and the link stays capable. Again here is the updated link:
https://www.dropbox.com/s/zj2i1votg432b2p/FrameTypes.pptx?dl=0
Please let me knwo your thoughts. I arranged the msgSpec with some optional fields up front for flexible use.
regards, robert
On 12/20/2015 06:20 AM, Clément Bera wrote:
Hello,
I tried to get your document but I got:
Dropbox - error
Is it only me ?
2015-12-20 11:31 GMT+01:00 Robert Withers <robert.w.withers@gmail.com mailto:robert.w.withers@gmail.com>:
Excuse me for failing to complete this email./ I wanted to ask for feedback on these structures, especially the header specification word structure. So these fields make sense? thank you, robert On 12/20/2015 05:27 AM, Robert Withers wrote: I wrote up the various SecureSession frame types in presentation document, which you can get here: https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0 These are not yet implemented, but it is progressing. Ne quid nemis. thanks, -- . .. .. ^,^ robert
Good morning, just a few comments and questions..
1) current 4bits for msgVersion and 4bits for hdrType. With 14 messages and some not implemented (suspend/resume/...) we have little headroom in 4bits of hdrType. Shall I make the msgVersion 3bits and the hdrType 5bits?
2) the smallest interleaved FEC encoded msg is 30 bytes. With 8 bytes of data: a msgSpec, using RS(15,9) with 4bit symbols, and 4 symbol block interleaving, the smallest on the wire is 30 bytes. Without FEC enabled is it 8 bytes.
3) when run to the end of hdrType room, we can add a jump tag and have a second hdrType field as the 9th byte.
Again, the valid document link is: https://www.dropbox.com/s/zj2i1votg432b2p/FrameTypes.pptx?dl=0
Thank you, robert
On 12/20/2015 06:20 AM, Clément Bera wrote:
Hello,
I tried to get your document but I got:
Dropbox - error
Is it only me ?
2015-12-20 11:31 GMT+01:00 Robert Withers <robert.w.withers@gmail.com mailto:robert.w.withers@gmail.com>:
Excuse me for failing to complete this email./ I wanted to ask for feedback on these structures, especially the header specification word structure. So these fields make sense? thank you, robert On 12/20/2015 05:27 AM, Robert Withers wrote: I wrote up the various SecureSession frame types in presentation document, which you can get here: https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0 These are not yet implemented, but it is progressing. Ne quid nemis. thanks, -- . .. .. ^,^ robert
My apologies for #2 below; what I said is wrong. The smallest message will be 8 bytes, as the messageSpecification is not FEC encoded. I will repair the doc as there are some issues with the spec and layout...done. Once again the link is: https://www.dropbox.com/s/zj2i1votg432b2p/FrameTypes.pptx?dl=0
* MessageSpecification is 8 bytes binary encoded. * Header is always asn.1 encoded * All messages may be FEC encoded with the FEC header asn.1 encoded. * Data Message payload is encrypted.
Change query: Regarding the Message Specification, with a hdrSize...I don't think we need it. The message size includes everything + the 8 bytes spec. The hdrType will specify the kind of message and header. The specific header knows it's own size and layout. Therefor, we have 16bits free if we keep an 8 byte msgSpec. Let's rework it to a 7 byte msgSpec as below. Perhaps it is useful to be 64bit aligned, so leave it at 8. Thoughts? Does this work?
*msgSpec: 7 bytes binary encoded*
* HeaderSpecification: 3 bytes o multicastSymbol: 6 bits o sanguinity: 7 bits o msgVersion: 5 bits o hdrType: 6 bits * msgSize: 2nd word, 4 bytes o 4 bytes (total size with msgSpec, header, payload sizes)
regards, robert
On 12/20/2015 07:01 AM, Robert Withers wrote:
Good morning, just a few comments and questions..
1) current 4bits for msgVersion and 4bits for hdrType. With 14 messages and some not implemented (suspend/resume/...) we have little headroom in 4bits of hdrType. Shall I make the msgVersion 3bits and the hdrType 5bits? 2) the smallest interleaved FEC encoded msg is 30 bytes. With 8 bytes of data: a msgSpec, using RS(15,9) with 4bit symbols, and 4 symbol block interleaving, the smallest on the wire is 30 bytes. Without FEC enabled is it 8 bytes. 3) when run to the end of hdrType room, we can add a jump tag and have a second hdrType field as the 9th byte.Again, the valid document link is: https://www.dropbox.com/s/zj2i1votg432b2p/FrameTypes.pptx?dl=0
Thank you, robert
On 12/20/2015 06:20 AM, Clément Bera wrote:
Hello,
I tried to get your document but I got:
Dropbox - error
Is it only me ?
2015-12-20 11:31 GMT+01:00 Robert Withers <robert.w.withers@gmail.com mailto:robert.w.withers@gmail.com>:
Excuse me for failing to complete this email./ I wanted to ask for feedback on these structures, especially the header specification word structure. So these fields make sense? thank you, robert On 12/20/2015 05:27 AM, Robert Withers wrote: I wrote up the various SecureSession frame types in presentation document, which you can get here: https://www.dropbox.com/s/3xfa5oqs8ihj88v/FrameTypes.pptx?dl=0 These are not yet implemented, but it is progressing. Ne quid nemis. thanks, -- . .. .. ^,^ robert-- . .. .. ^,^ robert
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)
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
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
More, sorry. I left out the msgSize in the FEC spec. Let me reorder the tagging, fit the 3 bytes of normal msgSpec into 4bytes and thusly...
---Default non-FEC msgSpec + header + payload layout:
- 8bytes (X) messageSpecification... - - (32bits...) - 4bits tagging - 6bits multicastSymbol - 6bits messageVersion - 2bits sanguinity - 6bits headerType "Implies Y header size. NOTE: except for FEC encodings" - 8bits unused - (32bits...) - 4bytes messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) - 8bytes msgSpec (X = 8)) - - Ybytes message header - - Zbytes message payload
Special FEC coded 64bit <msgSpec + header> + payload layout, for 64bit alignment:
- 8bytes (X) message specification... - - (32bits...) - 4bits tagging - 6bits multicastSymbol - 6bits messageVersion - 2bits sanguinity - 6bits FEC message type "NOTE: this means different layout" - 2bits rsMode - 6bits partial blockCount - (32bits...) - 4bits blockCount "NOTE: for 1MB encoded/982KB data - blockCount * blockCodeBytes = Z" - 20bits messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) - 8bytes msgSpec (X = 8)) "NOTE: this can specify 1MB data" - 8bits primitivePolynomial spec (good for our current rsModes) - - Y = 0 - - Zbytes-sized payload
Ok, that's what it is I think, this proposal.
robert
On 12/20/2015 10:33 AM, Robert Withers wrote:
---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
I updated with all the feedback and here is a version 1.0 pdf specification. I appreciate any comments or suggestions you may have for this.
https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0
Thank you, Robert
On 12/20/2015 10:51 AM, Robert Withers wrote:
More, sorry. I left out the msgSize in the FEC spec. Let me reorder the tagging, fit the 3 bytes of normal msgSpec into 4bytes and thusly...
---Default non-FEC msgSpec + header + payload layout:
- 8bytes (X) messageSpecification...
- (32bits...)
- 4bits tagging
- 6bits multicastSymbol
- 6bits messageVersion
- 2bits sanguinity
- 6bits headerType "Implies Y header size. NOTE: except for FEC
encodings"
- 8bits unused
- (32bits...)
- 4bytes messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) -
8bytes msgSpec (X = 8))
- Ybytes message header
https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0
- Zbytes message payload
Special FEC coded 64bit <msgSpec + header> + payload layout, for 64bit alignment:
- 8bytes (X) message specification...
- (32bits...)
- 4bits tagging
- 6bits multicastSymbol
- 6bits messageVersion
- 2bits sanguinity
- 6bits FEC message type "NOTE: this means different layout"
- 2bits rsMode
- 6bits partial blockCount
- (32bits...)
- 4bits blockCount "NOTE: for 1MB encoded/982KB data -
blockCount * blockCodeBytes = Z"
- 20bits messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) -
8bytes msgSpec (X = 8)) "NOTE: this can specify 1MB data"
- 8bits primitivePolynomial spec (good for our current rsModes)
- Y = 0
- Zbytes-sized payload
Ok, that's what it is I think, this proposal.
robert
On 12/20/2015 10:33 AM, Robert Withers wrote:
---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
I call these evolutions refinements. A few more here, pardon the bandwidth:
`1 - It was unspecified but the 4 tag bits can have 16 values, 1 for this protocol. The availability of 15 other protocols is a feature for open-source development. `2 - a header is easily defined for different transports and networks. `3 - the header of a FEC message is separately FEC encoded and interleaved with RS(15,9), so 30 bytes for the msgSpec and header, followed by the rsMode specified FEC encoding of the payload, padded out from msgSize.
thank you, robert
On 12/21/2015 08:42 PM, Robert Withers wrote:
I updated with all the feedback and here is a version 1.0 pdf specification. I appreciate any comments or suggestions you may have for this.
https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0Thank you, Robert
On 12/20/2015 10:51 AM, Robert Withers wrote:
More, sorry. I left out the msgSize in the FEC spec. Let me reorder the tagging, fit the 3 bytes of normal msgSpec into 4bytes and thusly...
---Default non-FEC msgSpec + header + payload layout:
- 8bytes (X) messageSpecification...
- (32bits...)
- 4bits tagging
- 6bits multicastSymbol
- 6bits messageVersion
- 2bits sanguinity
- 6bits headerType "Implies Y header size. NOTE: except for FEC
encodings"
- 8bits unused
- (32bits...)
- 4bytes messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y)
- 8bytes msgSpec (X = 8))
- Ybytes message header
https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0
- Zbytes message payload
Special FEC coded 64bit <msgSpec + header> + payload layout, for 64bit alignment:
- 8bytes (X) message specification...
- (32bits...)
- 4bits tagging
- 6bits multicastSymbol
- 6bits messageVersion
- 2bits sanguinity
- 6bits FEC message type "NOTE: this means different layout"
- 2bits rsMode
- 6bits partial blockCount
- (32bits...)
- 4bits blockCount "NOTE: for 1MB encoded/982KB data -
blockCount * blockCodeBytes = Z"
- 20bits messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y)
- 8bytes msgSpec (X = 8)) "NOTE: this can specify 1MB data"
- 8bits primitivePolynomial spec (good for our current rsModes)
- Y = 0
- Zbytes-sized payload
Ok, that's what it is I think, this proposal.
robert
On 12/20/2015 10:33 AM, Robert Withers wrote:
---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
-- . .. ... ^,^ robert Go Panthers!
vm-dev@lists.squeakfoundation.org
-
Clément Bera -
Robert Withers