Refinements.. Re: SecureSession protocol version 1.0 ( was Re: [Vm-dev] Re: SecureSession frame types)

Robert Withers <robert.w.withers@gmail.com> Tue, 22 December 2015 02:55 UTC

Return-Path: <robert.w.withers@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E281AD2EE; Mon, 21 Dec 2015 18:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7-01pyKfiF0; Mon, 21 Dec 2015 18:55:46 -0800 (PST)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFCE1AD2EC; Mon, 21 Dec 2015 18:55:46 -0800 (PST)
Received: by mail-vk0-x22e.google.com with SMTP id j66so111023662vkg.1; Mon, 21 Dec 2015 18:55:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=jLi9dmA//hD3zhQAM7SRN193A7qIXUB6M67IoVit5ps=; b=zXN6r7Y5YOssiUIGieiYY76uUJLSpz4vD4f6YUrLMaGBNvMRteg9/WinDaVbh7xVDM BiGoQN2PNM0OnxG9nj7fCD6cLRi2mYDJe/rPsUdqFLMuAbpMix0QrqcvhmIl7d2A/3co pTiQ/mq1hLG0bCxwSYzNtsru1xWvojksJ8yOUcMurTw2NJZ8+Z7/yV/OF8gVoo9MT6bk jP/AEv0bl1QEpf+aTrJzt5TstObO6NJbukRTjQg5TdsM+p4euopJKQoIDZNI0mjsehLo UERIn+Lv3fnOJoidc7FZmXbsZFHTJERHJMiNC9t2nq7JpkM3s7ufHxGT0iX7g/2MUckQ +9rA==
X-Received: by 10.31.47.204 with SMTP id v195mr14933174vkv.119.1450752945577; Mon, 21 Dec 2015 18:55:45 -0800 (PST)
Received: from [172.20.10.3] ([172.56.4.10]) by smtp.gmail.com with ESMTPSA id b9sm4009283vke.25.2015.12.21.18.55.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Dec 2015 18:55:44 -0800 (PST)
Subject: Refinements.. Re: SecureSession protocol version 1.0 ( was Re: [Vm-dev] Re: SecureSession frame types)
To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org>, Pharo Development List <pharo-dev@lists.pharo.org>, 5gangip@ietf.org, IETF Discussion <ietf@ietf.org>
References: <56768277.3020207@gmail.com> <56768388.8000902@gmail.com> <CAJrdCbUzA=X3s3FmW+pF09P5iqJ7q=DWp9am-i=xcf1czxGzkQ@mail.gmail.com> <5676989D.8020201@gmail.com> <5676B92C.4070101@gmail.com> <5676BC53.4050800@gmail.com> <5676BFA0.10403@gmail.com> <5676CA3A.3050801@gmail.com> <5676CE87.4050305@gmail.com> <5678AA74.9010108@gmail.com>
From: Robert Withers <robert.w.withers@gmail.com>
Message-ID: <5678BBAE.6080902@gmail.com>
Date: Mon, 21 Dec 2015 21:55:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <5678AA74.9010108@gmail.com>
Content-Type: multipart/alternative; boundary="------------070808040707050905070808"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/vZHlCgPEOZFl-cugkx4Xk4ix_FI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2015 02:55:49 -0000

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=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
>>
>
> -- 
> . ..  ...   ^,^    robert
> Go Panthers!

-- 
. ..  ...   ^,^    robert
Go Panthers!