[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Noticed some possible errors in the ULE draft, ANNEX A
Dear Juan,
Juan Cantillo wrote:
Dear Bernhard,
Thanks for your prompt revision of the ULE draft and reply, I am glad
that those typos won't make it to the RFC Editor!
thanks to you.
On the other hand I totally agree with the fact that the examples are
hard to read, and this is due to 2 factors:
1- "SNDU A is n bytes" actually means that the "Length" field of the
ULE header carries the value (n-4). However this value is referred in
the drawings as "SNDU Length", which was just defined as "n" and not
"(n-4)"... this is pretty much confusing indeed.
The reason (but maybe more an excuse) for this fact is that the SNDU
Length is earlier in the document (quite) well described in 2.4:
A 15-bit value that indicates the length, in bytes, of the SNDU
counted from the byte following the Type field, up to and including
the CRC. Note the special case described in 4.3.
I am already discussiong with Gorry whether the "following the Type
field" explaination is clear enough, because maybe "following the 4B ULE
base header" is cleare. What do you think?
2- bytes A000, A001, A002 are *NEVER* explicitely drawn, so their
position inside the TS packet is not clear. In addition, the fact that
the Length Field is shown makes almost think that it does not belong to
the SNDU. This might suggest that A000 is maybe the first byte after the
Length field... which turns to be in fact A002 (first byte of Type field).
As said, the attempt to include the SNDU Length field value in the
examples did not necessarily add to ease of understanding.
IMHO, and for the sake of clarity,something like this could be added to
the beginning of Annex A:
====================================================================
When stated that "SNDU A is n bytes", the n bytes of SNDU A are
labelled from A000 to A(n-1), where:
*Bytes A000 and A001 represent the 16 bits of the D-bit and the Length
field. Those 2 bytes are referred in the following diagrams as "SNDU
Length", and carry the decimal value:
(n-4) if D-bit is 0
(2^15+n-4) if D-bit is 1
written in hexadecimal notation.
*Bytes A(n-4), A(n-3), A(n-2) and A(n-1) carry the CRC of SNDU A.
===================================================================
What do you think of this suggestion?
Personally I think that is an very good suggestion. What do others think?
One could get the impression that after the early adopters/implementers
of ULE not many did the exercise again...
Best regards,
Juan C.
Kind regards,
Bernhard
----- Original Message ----- From: "Bernhard Collini-Nocker"
<bnocker@cosy.sbg.ac.at>
To: <ipdvb@erg.abdn.ac.uk>
Sent: Tuesday, August 23, 2005 9:31 AM
Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A
Dear Juan,
many thanks for this hints. You are perfectly right, some wrong
numbers have made it into the document, which need to be corrected
before publication.
For curiosity I checked the earlier versions of the drafts and it
looks as if the first problem of this kind (calculating the Length
field as being length of SNDU including header, so 4 bytes too much)
first occurred in the Feb 2004 -02 version, (was actually meant as an
improvement for reading: instead of showing the SNDU bytes from 0 to
length-1 to also provide the Length field values). In the Oct 2004 -02
version this first calculation error was corrected for the first
example, but at the same time the second example was "improved" with
completely obscure numbers (6x instead of Bx). Funny enough, in the
same -02 version another two examples were correctly improved, yet
another one with same kind of +4 calculation.
Apart from Yuan, again many thanks for this detailed reading, no one
seems to have recalculated or cross checked the numbers again since then.
Rethinking this style of reading improvement it does not seem to be
such that the examples are easier to understand at all.
If one takes for example the first part of Example A.5 (is just the
shortest one) I find it not that clear any more that SNDU A having
length 52 (4B hdr plus 48B payload) is to be counted from A000 to A051
on one side, but since the SNDU Length field is shown the counting
actually has to start with A002 o nthe other side.
Any hints for improvement?
Example A.5: Three 44B PDUs.
SNDU A is 52 bytes (no ULE destination NPA address)
SNDU B is 52 bytes (no ULE destination NPA address)
SNDU C is 52 bytes (no ULE destination NPA address)
The sequence comprises 1 TS Packet:
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+-----+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-
PUSI=1 * *
*****
The sequence comprises 1 TS Packet:
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+-----+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x34 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-
PUSI=1 * *
*****
Regards,
Bernhard
Gorry Fairhurst wrote:
Juan, thanks for the query it's easy to miss mistakes in the
informative annexes, and we'd certainly like to get the text correct
before this is published as a RFC.
Can someone please check this out (I can't at the momment)
Gorry
Juan Cantillo wrote:
Dear Gorry,
I am currently working on the "01 version" of our DVB-S2 draft and
while re-reading the ULE-06 draft I came across what might be some
typographic errors in ANNEX A:
********************* Page 38, example A2 "Usage of last byte in a
TS packet":***************
The 4 shown SNDU sizes are 183, 182, 181 and 185 Bytes long, which
would lead to "SNDU Length" fields of 0xB3, 0xB2, 0xB1and 0xB5,
resp, since:
0xB3 = 183 - 4 (in decimal)
0xB2 = 182 - 4
0xB1 = 181 - 4
0xB5 = 185 - 4
(4 bytes are to be substracted to the length of the SNDU since the
"SNDU Length" field DOES NOT count the 4-byte mandatory header of ULE)
Instead, in the diagram we have 0x63, 0x62, 0x61and 0x65... it seems
that the "B" was confused with "6" ?!
********************* Page 41, example A5 "three 44B
PDUs":********************************
The three SNDUS are 52 bytes long, which would lead to "SNDU Length"
of 48 bytes, coded in hexadecimal as 0x30 and NOT as 0x34.
Please let me know whether those are typographic mistakes, or if it
is me who is wrong... This last hypothesis is highly probable since
"the errors" are similar, so I might be missing something!
Looking forward to hearing from you soon,
Juan
=========================
Juan CANTILLO
SatComs PhD. Researcher
ENST/TeSA/ENSICA/ASP
+33 6 23 54 59 65
Toulouse, FR