Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[RE] Synchronous ethernet discussions



All,

We had quite a few adhoc like teleconferences before
the Residential Ethernet became a study group. I found
these to be very helpful, and we now have an official
reflector to continue that activity.

I'll throw out a few ideas for discussion, to stimulate
such activities. Please respond if you deem this inappropriate
(in which case I will stop) or continue with criticisms,
refinements, or alternative concepts.

It seems like there are a few issues to be addressed,
including:

1) Synchronous frame formats. Should we:
   a) Is a synchronous frame simply an frame with a distinct
      typeLength field?
   b) Is a synchronous frame a collection of subframes,
      so that it can be more compact, but easily converted
      into real frames in a context-free manner?
   c) Is a synchronous frame a collection of data chunks,
      so that it can be most compact, but only converted
      into real frames in a context-dependent manner, based
      on setup information stored in the bridge and/or
      destination?
  DVJ preferences:
    1a or 1b, with 1b if necessary for efficiency.

2) Bandwidth allocation. How does the "system" ensure that
   the bandwidth allocations on any specific link do not
   exceed its capacity?
   a) A central manager.
   b) Connection-establishment information flows through
      bridges, over the same path that the data will follow.
  DVJ preferences:
    2a, as bridges are done today.

3) Frame timing.
   a) Do we support jumbo frames on 100Mb, in which case it
      may be necessary to preempt nonsynchronous frames?
   b) Is a form of synchronous timing necessary, to avoid
      bunched traffic that exceeds the link capacity?
  DVJ preferences:
   3a) No strong opinions.
   3b) Yes, 125us seems to be a good number.

4) Clock-synchronization accuracies.
   a) Is application level synchronization sufficient?
   b) Does data have to be closely synchronized with the clock?
  DVJ preferences:
   4a) No. Some lower-level hardware snapshot hardware is needed.
   4b) No. Data frame jitter can be much larger (a few 125us cycles)
       than an acceptable jitter error in synchronized clocks.

Some thoughts to stimulate some conversation...

DVJ


David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
      +1.650.856.9801
Cell: +1.650.954.6906
Fax:  +1.360.242.5508
Base: dvj@alum.mit.edu