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

[Gorry Fairhurst]

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 <gardikis at iit.demokritos.gr>
Reply-To: ipdvb at erg.abdn.ac.uk
To: ipdvb at erg.abdn.ac.uk
References: <46F15056.90004 at erg.abdn.ac.uk>

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