[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Noticed some possible errors in the ULE draft, ANNEX A
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!
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.
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).
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?
Best regards,
Juan C.
----- 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