| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Thanks for putting this together. A few comments: ·
We had previously discussed in our meetings that sequence numbers would be used for constant data rate uses (like tunneling and agnostic modes) and for control packets; the use of sequence numbers allows you to determine if you
have missed a packet in these cases. The cases where you have variable (non-constant) traffic are where it makes the most sense to use timestamps. Both of these scenarios have some issues if timescales on each end diverge. ·
Constant data rate:
o
If timestamp and sequence number are used, which has priority if there’s a conflict?
o
Suppose a constant rate queue hasn’t emptied by the time a timestamped packet comes in: do you delay the timestamped data until the queue has emptied, or do you drop bits/bytes to deliver that data according to the timestamp?
o
Conversely, suppose the timestamp for a constant rate flow is slightly after the time that the queue empties: do you repeat old bits, or do you glitch the data stream to align with the new timestamp?
o
If it’s a constant rate flow, I don’t see value in timestamps (other than in starting and stopping the flow through control packets). ·
Variable data rate:
o
Variable rate data expects to have some gaps, so an under-run isn’t a problem; but what about an over-run?
o
Suppose packet N has 600 bytes of data to be sent at a specific time and at the rate that was identified when the flow was set up. Now suppose packet N+1 comes in with a presentation time that indicates a presentation time slightly
before all 600 bytes have been sent—what do you do in such an instance? For constant rate data, I don’t think we should do anything in RoE to re-align timescales. I think that the RoE equipment should adapt their clocks to match the timing of their time references, whether that’s GNSS, cesium oscillator, SyncE,
1588, or other mechanisms. In the case of 1588, the ITU-T recommendations are to do a minimum of 16 sync messages per second, so the RoE equipment should receive time updates frequently through that protocol—and we don’t need to replicate that in RoE. Even
worse, the mechanism in RoE could conflict with more mature technologies available to RoE members. --kb ------------------------------------------------------------------ 1904.3 members: As a follow up to the discussion we had at the Feb/2016 plenary, I would like to look more deeply at data path vs control path time distribution mechanisms when the client and the Ethernet network have different timescales. Please see
the attached presentation. We can discuss this at the next call on Tuesday.
Richard Tse Senior Principal Engineer Microsemi 8555 Baxter Place Burnaby, BC Canada V5A 4V7 Phone: +1-604-415-6015 Email: Richard.Tse@xxxxxxxxxxxxx Web: www.microsemi.com
|