Subject: A proposal for a link timestamp option for ULE/GSE - Comments?

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 27 Feb 2007 09:37:19 +0000

I've written the propsoal below as a candidate (if useful) for inclusion 
in the ULE extension header draft.

I realise there may be some debate about how to fix a sensible timestamp 
value - so here is a first attempt via the list to see if others have 
any comments or ideas...

Clearly there are many options for representation, including ...
"A resolution of 20 microseconds. The 32-bit value therefore indicates 
the number of 20 microsecond ticks past midnight Universal Time when the 
timestamp option was inserted, right-justified to the 32-bit field."

All thoughts are welcome!

Best wishes,

Gorry

---

Timestamp Extension Header

The timestamp extension is designed to support monitoring and 
measurement of ULE performance over a link to provide indications of the 
quality of an operational ULE link. It may be particularly useful for 
GSE links (where significant complexity exists in the scheduling 
provided by the lower layers). The extension permits an Encapsulator to 
insert an extension header while forming an SNDU. This extension may be 
(optionally) checked at the Reciever.

Possible uses of this extension include:

* Validation of in-sequence ordering per Logical Channel,
* Measurement of the one-way delay (when synchronised with the sender)
* Measurement of PDU Jitter introduced by the link,
* PDU loss (with additional information from the sender).

 >>> IANA please insert a value for the H-Type from the Next-Header 
Registry in the sentence below, and the figure following <<<

The Timestamp Extension Header is specified by the IANA-assigned H-Type 
of 0xTBD. The format of the Timestamp extension is shown in figure XX below.

  0               7               15              23              31
  +---------------+---------------+---------------+---------------+
  |     0x03      |H-Type = 0xTBD |       time stamp HI           |
  +---------------+---------------+---------------+---------------+
  |         time stamp LO         |            Type               |
  +---------------+---------------+---------------+---------------+

This extension is an Optional Extension Header ([RFC4326], Section 5).
Figure 2 shows the format of this extension with a HLEN value of 3 
indicating a timestamp of length 4B  plus a Type field.

The extension carries a 32-bit value (time stamp HI plus time stamp LO). 
The specified resolution is 1 microsecond. The value therefore indicates 
the number of 1 microsecond ticks past the hour in Universal Time when 
the timestamp option was inserted, right-justified to the 32-bit field. 
Systems unable to insert timestamps at the specified resolution may use 
an arbitary (and varying) value to pad the unused least-significant bits.

The last two bytes carry a 16-bit Type field that indicates the type of 
payload carried in an SNDU, or the presence of a further Next-Header, as 
defined in [RFC4326], Section 4.4.

This is an Optional Extension Header, Receivers that do not implement, 
or do not wish to process the Timestamp Extension MAY skip this 
extension and continue to process the remainder of the SNDU.

---

From: Georgios Gardikis <[email-masked]>
Date: Tue, 27 Feb 2007 12:40:53 +0200

It seems quite a good idea.
We often come to the point where we need to measure delay and jitter 
over DVB networks, and we have no choice but proprietary, IP-based 
methods. Including a timestamp at the encapsulation stage could be quite 
handy.
Also, in the GSE case (no MPEG-2 TS), this extension could act as a new 
PCR, providing encapsulator (rather than multiplexer) clock reference.

George

----------

Dr. Georgios Gardikis
Associate Researcher
NCSR "Demokritos", Institute of Informatics and Telecommunications
Athens 153 10, Greece
Tel: +30 210 650 3108
Fax: +30 210 653 2175

Gorry Fairhurst wrote:

>
> I've written the propsoal below as a candidate (if useful) for 
> inclusion in the ULE extension header draft.
>
> I realise there may be some debate about how to fix a sensible 
> timestamp value - so here is a first attempt via the list to see if 
> others have any comments or ideas...
>
> the number of 20 microsecond ticks past midnight Universal Time when 
> the timestamp option was inserted, right-justified to the 32-bit field."
>
> measurement of ULE performance over a link to provide indications of 
> the quality of an operational ULE link. It may be particularly useful 
> for GSE links (where significant complexity exists in the scheduling 
> provided by the lower layers). The extension permits an Encapsulator 
> to insert an extension header while forming an SNDU. This extension 
> may be (optionally) checked at the Reciever.
>
> The Timestamp Extension Header is specified by the IANA-assigned 
> H-Type of 0xTBD. The format of the Timestamp extension is shown in 
> figure XX below.
>
>  0               7               15              23              31
> The extension carries a 32-bit value (time stamp HI plus time stamp 
> LO). The specified resolution is 1 microsecond. The value therefore 
> indicates the number of 1 microsecond ticks past the hour in Universal 
> Time when the timestamp option was inserted, right-justified to the 
> 32-bit field. Systems unable to insert timestamps at the specified 
> resolution may use an arbitary (and varying) value to pad the unused 
> least-significant bits.
>
> The last two bytes carry a 16-bit Type field that indicates the type 
> of payload carried in an SNDU, or the presence of a further 
> Next-Header, as defined in [RFC4326], Section 4.4.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 27 Feb 2007 10:45:54 +0000

Are there timing constraints on the PCR that you would expect to need 
for GSE, that would imply a certain required timestamp resolution?

Gorry

---

From: Georgios Gardikis <[email-masked]>
Date: Tue, 27 Feb 2007 14:38:51 +0200

The granularity of the PCR goes down to 37 nsec and the maximum PCR 
jitter allowed is 500 nsec.
The PCR field is 42 bits, and wraps around every 26 hours (it is an 
incremental counter than a distance from midnight).
Maybe we could increase the resolution of the proposed timestamp to be 
more accurate.

George

Dr. Georgios Gardikis
Associate Researcher

Gorry Fairhurst wrote:

>> methods. Including a timestamp at the encapsulation stage could be 
>> quite handy.
>> Also, in the GSE case (no MPEG-2 TS), this extension could act as a 
>> new PCR, providing encapsulator (rather than multiplexer) clock 
>> reference.
>>
>> George
>>
>> ----------
>>
>> Dr. Georgios Gardikis
>> Associate Researcher
>>> "A resolution of 20 microseconds. The 32-bit value therefore 
>>> indicates the number of 20 microsecond ticks past midnight Universal 
>>> 32-bit field."
>>> the quality of an operational ULE link. It may be particularly 
>>> useful for GSE links (where significant complexity exists in the 
>>> scheduling provided by the lower layers). The extension permits an 
>>> Encapsulator to insert an extension header while forming an SNDU. 
>>> This extension may be (optionally) checked at the Reciever.
>>>
>>> indicates the number of 1 microsecond ticks past the hour in 
>>> Universal Time when the timestamp option was inserted, 
>>> right-justified to the 32-bit field. Systems unable to insert 
>>> timestamps at the specified resolution may use an arbitary (and 
>>> varying) value to pad the unused least-significant bits.
>>>
>>> This is an Optional Extension Header, Receivers that do not 
>>> implement, or do not wish to process the Timestamp Extension MAY 
>>> skip this extension and continue to process the remainder of the SNDU.
>>>
>>>
>>>
>>>
>>
>>
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 27 Feb 2007 15:32:07 +0000

So...

For Packet performance tests over links at 100's Mbps, perhaps 
microsecond accuracy would be sufficient?

For a PCR/NCR we're speaking of regenerating high-stability clocks. 
Finer resolution may be good (as in the existing NCR/PCR), but then it 
is important to also provide rules for placement in the transmission 
frames (as Ulrik mentioned). I'm not against a higher-resolution (a 
64-bit version????).

Should we separate these two functions? or do we need to look at 
something that covers both?

Gorry

---

From: johanfirdi <[email-masked]>
Date: Wed, 28 Feb 2007 08:11:18 +0700

Hi Georgios,

how do u calculate PCR number come to37 nsec ?. and maximum allowed is 
500 nsec.
Do u have paper for this ?.
Thanks

Johan

Georgios Gardikis wrote:
>>>> indicates the number of 20 microsecond ticks past midnight 
>>>> right-justified to the 32-bit field."
>>>>
>>>> measurement of ULE performance over a link to provide indications 
>>>> of the quality of an operational ULE link. It may be particularly 
>>>> The last two bytes carry a 16-bit Type field that indicates the 
>>>> type of payload carried in an SNDU, or the presence of a further

---

From: Klaus Würflinger <[email-masked]>
Date: Wed, 28 Feb 2007 09:38:01 +0100

Hi Johan,

PCR is defined in ISO/IEC 13818-1 to be 27MHz => 1/27MHz ~ 37ns.
PCR jitter limits are standardised in ETSI TR 101290.
ETSI standards are available for free download at www.etsi.org

Regards,
Klaus

-- 
Klaus Würflinger
Multimedia Communications Group
Dept. of Computer Sciences
Paris Lodron University Salzburg
Jakob-Haringer-Str. 2
5020 Salzburg, Austria
T: (+43)662/8044-6332
F: (+43)662/8044-172
E: [email-masked]