Kevin,
OK with me.
- Jouni
From: Bross, Kevin [mailto:kevin.bross@xxxxxxxxx]
Sent: Monday, November 09, 2015 8:58 AM
To: Jouni Korhonen; stds-1904-3-tf@xxxxxxxx
Subject: RE: hillsboro aftermath: timestamps/sequence numbers
Better graphics, thanks. My thoughts are as follows:
1.
We should consider a neutral name for this 32-bit field, such as
Ordering Indicator or something similar. The Ordering Indicator field would have two primary uses:
a.
Sequence numbering
b.
Timestamps
2.
For sequence numbering, we can use the arrangement like you’ve indicated below.
3.
Since we have a 32-bit
Ordering Indicator field that wraps around to a second line, I’m merely suggesting that we show the
Ordering Indicator field’s two halves as following:
a.
Ordering Indicator (Upper WORD)
or
Ordering Indicator (Upper 16 bits)
b.
Ordering Indicator (Lower WORD)
or
Ordering Indicator (Lower 16 bits)
c.
These would still be a single 32-bit field that could partitioned as we determine. I was just looking for visual clarity on the packet header layout as we show it in the spec.
--kb
------------------------------------------------------------------
Kevin Bross
===================================================================
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Sent: Monday, November 09, 2015 6:24 AM
To: Bross, Kevin; stds-1904-3-tf@xxxxxxxx
Subject: RE: hillsboro aftermath: timestamps/sequence numbers
Resending the graphics.. There seemed to be issues with the graphics.
From: Jouni Korhonen
Sent: Sunday, November 08, 2015 10:05 PM
To: 'Bross, Kevin'; stds-1904-3-tf@xxxxxxxx
Subject: RE: hillsboro aftermath: timestamps/sequence numbers
Kevin,
Regarding 3. this is what I think we agreed during the meeting:
<< OLE Object: Picture (Device Independent Bitmap) >>
Where 0 <= q <= p < 32
- Jouni
From: Bross, Kevin [mailto:kevin.bross@xxxxxxxxx]
Sent: Thursday, November 05, 2015 6:07 PM
To: Jouni Korhonen; stds-1904-3-tf@xxxxxxxx
Subject: RE: hillsboro aftermath: timestamps/sequence numbers
Jouni,
Looks good. A few related thoughts:
1.
I think we should dump the extended header terminology entirely. Each pkt_type will determine the format of the payload.
2.
Should the use of timestamp or sequence be a function of pkt_type and flow_id, or should it be a function purely of pkt_type? [I think I would prefer the latter.]
3.
Does it make sense to break the timestamp/sequence into “Timestamp/sequence High Word” and “Timestamp/sequence Low Word”? This would still be a 32-bit composite field, but we could graphically
show the position of the high word and the low word in the packet layout diagrams like you show below.
Going with the logic that simpler is often better, I like how the header has simplified over the course of our discussions.
--kb
===================================================================
From:
stds-1904-3-tf@xxxxxxxx
[mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Jouni Korhonen
Sent: Thursday, November 05, 2015 11:22 AM
To: stds-1904-3-tf@xxxxxxxx
Subject: hillsboro aftermath: timestamps/sequence numbers
Folks,
Coming back to discussion we had and kind of was let hanging on my next steps.. so the T-flag and alternating between sn/ts.. I am actually OK to
go with what was proposed during the meeting and toss the T-flag. If we need timestamps that can be decided per flow_id and packet type.
If folks agree with the above we would end up to a header as below:
<< OLE Object: Picture (Device Independent Bitmap) >>
So, everybody happy with this? I did collapse the extended_header_space and the payload into the same illustration, since they essentially are the
same (subject to the packet type).
- Jouni
--
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M: +1-408-391-7160