|
Dear Bernhard,
When I first read the draft, the
explanation:
" 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."
was quite clear to me (and it
still is), so in my opinion this shouldn't be modified.
The confusion came only when
reading the examples, for the reasons (and the errors) mentionned in the
previous mails, and that
is why I consider that something should be done in order to improve their
readability. The addition
of the lines I proposed might address this issue... but of course, we hope there
will be some other proposals and/or feedback
from the list on this subject.
Best regards,
Juan C.
----- Original Message -----
Sent: Wednesday, August 24, 2005 6:00
PM
Subject: 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
>>>
>>>
>>>
>>
>>
>
>
|