Reminder: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-ule-ext-04.txt
gardikis at iit.demokritos.gr
Thu Sep 27 11:03:41 BST 2007
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
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.
Dr. Georgios Gardikis
NCSR "Demokritos", Institute of Informatics and Telecommunications
Athens 153 10, Greece
Tel: +30 210 6503108
Fax: +30 210 6532175
O/H 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.
> -------- 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.
> 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
More information about the Ip-dvb