Re: [Vm-dev] Re: SecureSession frame types

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

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 <[hidden email]>:

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
• multicastSymbol: 6 bits
• sanguinity: 7 bits
• msgVersion: 5 bits
• hdrType: 6 bits
• msgSize: 2nd word, 4 bytes
• 4 bytes (total size with msgSpec, header, payload sizes)

regards,
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 <[hidden email]>:

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...

• HeaderSpecification: 3 bytes
• multicastSymbol: 6 bits
• sanguinity: 6 bits
• msgVersion: 6 bits
• hdrType: 6 bits
• msgSize: 2nd word, 4 bytes
• 4 bytes (total size with msgSpec, header, payload sizes)