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

[Georgios Gardikis]

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
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.
>
> 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
>