Subject: Reminder: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-ext-04.txt

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 19 Sep 2007 17:37:42 +0100

If you would like to see this document published as an RFC (or propose 
to implement this, etc), please send an email to this list BEFORE the 
deadline of midnight GMT, 26th September 2007.

On the other hand, if you feel the document should be returned to the WG 
for further work, or that issues still need to be addressed, please also 
say!

Best wishes,

Gorry

-------- Original Message --------

This note starts the WG two week Last-Call for comments for the WG
document named below:

Extension Formats for Unidirectional Lightweight Encapsulation (ULE)
and the Generic Stream Encapsulation (GSE)

http://tools.ietf.org/html/draft-ietf-ipdvb-ule-ext-04.txt

This Last-Call will end on midnight GMT, 26th September 2007.

Members of the IETF ipdvb WG are asked to read the above draft and send
any issues, comments, or corrections to this mailing list. The WGLC
procedure is the last chance for this working group to modify/correct
this document.

Please do forward any comments to the list. The document shepherd for
the process following completion of the WGLC shall be the ipdvb
Secretary (Martin Stiemerling) <[email-masked]>).

Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)

---

From: Georgios Gardikis <[email-masked]>
Date: Tue, 25 Sep 2007 12:37:08 +0300

Dear Gorry, all,

I think that the candidate RFC is a well-written and clear document, and 
the extensions proposed are quite useful.
My only concern, which I had already expressed, is that the timestamp 
resolution (1 msec) might be inadequate, especially when current 
MPEG-2-based timing mechanisms (NCR/PCR) go down to a few nsecs.

Anyway, my vote is positive.

Regards

G. Gardikis

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

O/H Gorry Fairhurst έγραψε:
> On the other hand, if you feel the document should be returned to the 
> WG for further work, or that issues still need to be addressed, please 
> also say!
>
> Best wishes,
>
> Gorry
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 27 Sep 2007 08:32:45 +0100

Georgios, the current size of field/resolution was focussed on the 
discussion of using a TS for link management/monitoring (detecting 
packet loss, jitter, reordering) - not as a replacement for the PCR/NCR 
within a MPEG-2 network.

I'd like to better understand what you are thinking. If I recall, the 
previous thread was centred on using stream time stamps as a future 
method to support L2 timing services equivalent to PCR and NCR, and 
perhaps other uses (I guess inserting these is an implementation detail 
!). Is this what you had in mind?

This could be the right document to define these if we could live with 
both having the same extension type value... For instance, the extension 
header mechanism COULD define TWO time formats for the time-stamp value 
with different HLEN (e.g. HLEN=3, which would indicate an Optional 
Extension Header of length 6B, Type + 4B timestamp?). Is this something 
like what you had in mind?

Please do reply to the list.

Gorry

-------- Original Message --------
Subject: Re: Reminder: WG Last-Call (WGLC) for comments: 
draft-ietf-ipdvb-ule-ext-04.txt
Date: Tue, 25 Sep 2007 12:37:08 +0300
From: Georgios Gardikis <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
References: <[email-masked]>

Dear Gorry, all,

Regards

G. Gardikis

Dr. Georgios Gardikis
Associate Researcher

---

From: Georgios Gardikis <[email-masked]>
Date: Thu, 27 Sep 2007 13:03:41 +0300

Hello Gorry, all,

I agree with you that 1 msec is generally enough for network-level 
measurements (packet delay, jitter, reordering etc.). However, even for 
this purpose, if we consider a 10-12Mbps service (rational value for 
H.264 Hi-Def streams), we could end up with almost 1000 SNDUs/sec. This 
could result in consecutive SNDUs having the same timestamp.

Moreover, I was thinking that our timestamp should have adequate 
precision, so that in the future it could replace NCR/PCR, even in cases 
where extreme timing accuracy is needed (e.g. in the case of DVB-RCS 
synchronisation)

I think it's not a big overhead to reserve some extra bytes for 
increased resolution. Of course, I agree that this "extra resolution" 
should be optional.
However, the use of two different extension type values makes thinks 
more complicated, and I believe that simplicity is a key point for the 
industrial adoption of the RFC.

To summarise, I think that the solution that you propose (two time 
formats, declared by two different HLEN values) is the best.

Best regards

Dr. Georgios Gardikis
Associate Researcher

O/H Gorry Fairhurst έγραψε:
> packet loss, jitter, reordering) - not as a replacement for the 
> PCR/NCR within a MPEG-2 network.
>
> perhaps other uses (I guess inserting these is an implementation 
> detail !). Is this what you had in mind?
>
> both having the same extension type value... For instance, the 
> extension header mechanism COULD define TWO time formats for the 
> time-stamp value with different HLEN (e.g. HLEN=3, which would 
> indicate an Optional Extension Header of length 6B, Type + 4B 
> timestamp?). Is this something like what you had in mind?
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 30 Sep 2007 07:40:22 +0100

Hello Georgios,

So, I am not sure I understand your numbers. In the current draft the 
authors are now proposing a 4 byte timestamp with a resolution of 1 
microsecond, in the following format:

     0               7               15              23              31
     +---------------+---------------+---------------+---------------+
     |     0x03      |      0x01     |       time stamp HI           |
     +---------------+---------------+---------------+---------------+
     |         time stamp LO         |            Type               |
     +---------------+---------------+---------------+---------------+

By my maths, 1 microsecond should be enough to identify the position of 
a small SNDU, of say 16 bytes (a ULE header, Timestamp option and NULL 
payload) unambiguously at a link rate up to 128 Mbps (with 1 million 
SNDUs per second), and a single SNDU with a 40 byte PDU at up to 448 Mbps.

The HLEN=3 indicates an Optional Extension Header of length 6B (Type + 
4B timestamp value). With a granuality of 1 microsecond, this gives a 
maximum value of just over 1 hour, after which the timestamp value wraps.

Do you think a higher resolution is required for the application that 
you describe?

Gorry