Re: [RE] Synchronous ethernet discussions
Hi All,
Being new to this effort for Residential Ethernet, my apologies
if my questions are too basic.
Has there been any material that gives overview about Digital
Home requirements re:
1. What is the topology targeted for the solution:
- Small network with one/two hops (bridges)?
- 10/100 only or can use 10/100/1000?
2. Is there any workload characterization?
- Packet sizes/distribution
- burstiness
3. What is the expected/acceptable performance criteria?
- Throughput at the end-station
- Latency/Latency jitter
- Packet drop sensitivity?
- clock sync need (with respect to what?)
4. Is any quantitative data available that shows above can not
be met on GiGE? (Except clock-sync). Pointer will certainly
help.
5. What is a synchronous frame? Pointer to any prior work will
really help.
Appreciate any feedback.
Thanks,
- Manoj
-----Original Message-----
From: owner-stds-802-3-re@listserv.ieee.org
[mailto:owner-stds-802-3-re@listserv.ieee.org] On Behalf Of David V
James
Sent: Wednesday, August 25, 2004 12:02 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: [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