Reminder: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-ext-04.txt
gorry at erg.abdn.ac.uk
Thu Sep 27 08:32:45 BST 2007
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.
-------- Original Message --------
Subject: Re: Reminder: WG Last-Call (WGLC) for comments:
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.
Dr. Georgios Gardikis
NCSR "Demokritos", Institute of Informatics and Telecommunications
Athens 153 10, Greece
Tel: +30 210 6503108
Fax: +30 210 6532175
More information about the Ip-dvb