[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,
 
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
>>>
>>>
>>>
>>
>>
>
>