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

[Gorry Fairhurst]

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