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 Georgios Gardikis wrote:
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.txtDate: Tue, 25 Sep 2007 12:37:08 +0300 From: Georgios Gardikis <gardikis@iit.demokritos.gr> Reply-To: ipdvb@erg.abdn.ac.uk To: ipdvb@erg.abdn.ac.uk References: <> 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