Re: [RE] Synchronous ethernet discussions
Manoj:
I believe you raise some of the basic questions which will need to be
addressed. I have looked thru the Digital Living Networking Alliance (DLNA)
papers to see if I could get some guidance. They address the needs from a high
level but don't provide much detail. As our companies are both members, maybe
we should initiate such an effort :)
Regarding topology, I see this as essentially a green field into which vendors
will bring new application driven devices using mostly existing 802.3 silicon.
That means the frame format does not change, we may use P2MP from 802.3ah and I
advocate the speed at 1 G. I believe that because your colleagues tell me that
1 GE will be on the motherboards in a year and with those kind of volumes, 1 GE
silicon will be cheaper than 100M. It will also give us plenty of b/w headroom
for interesting new HD video apps as the price of displays come down.
Regards,
Richard Brand
"Wadekar, Manoj K" wrote:
> 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
begin:vcard
n:Brand;Richard C.
tel;work:(408) 495 2462 : ESN 265 2462
x-mozilla-html:FALSE
org:Advanced Technology
adr:;;4655 Great America Pkway;Santa Clara;Ca.;95054;
version:2.1
email;internet:rbrand@Nortelnetworks.com
title:Director, Network Architecture & Applications
fn:Richard C. Brand
end:vcard