Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 22 Aug 2005 18:04:25 +0100

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

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Tue, 23 Aug 2005 09:31:31 +0200

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:
>> 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 
>> 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:
>> (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)
>> 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.
>>

---

From: "Juan Cantillo" <[email-masked]>
Date: Tue, 23 Aug 2005 18:14:01 +0200

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" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 23, 2005 9:31 AM
Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A

> 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.
>
>
> 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.
>

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Wed, 24 Aug 2005 18:00:40 +0200

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:

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...

> Juan C.

Kind regards,
Bernhard

> 
> ----- Original Message ----- From: "Bernhard Collini-Nocker" 
> <[email-masked]>
>> 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 
>> 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.
>>
>> Rethinking this style of reading improvement it does not seem to be 
>> such that the examples are easier to understand at all.
>>> 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.
>>>
>>>>  ********************* Page 38, example A2 "Usage of last byte in a 
>>>> TS packet":***************
>>>> would lead to "SNDU Length" fields of 0xB3, 0xB2, 0xB1and 0xB5, 
>>>> resp, since:
>>>>  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!

---

From: "Juan Cantillo" <[email-masked]>
Date: Mon, 29 Aug 2005 11:06:41 +0200

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 ----- 
  From: Bernhard Collini-Nocker 
  To: [email-masked] 
  Sent: Wednesday, August 24, 2005 6:00 PM
  Subject: Re: Noticed some possible errors in the ULE draft, ANNEX A

  Dear Juan,

  thanks to you.

  Kind regards,
  Bernhard