Re: [RE] Stream identification at the MAC SAP
Comments below ...
On 11/11/04 7:04 PM, "Matt Squire" <MSquire@HATTERASNETWORKS.COM> wrote:
>> Oddly enough, with Residential Ethernet (at least the way some
>> of us have been envisioning it), you could really toss the PBX out
>> the window without losing any quality of service.
>
> Seems like people have already tossed the PBX out the window, and they're not
> having any problems. So if that the benefit of RE, its a little late.
Some tossed the PBX, the vast majority have not. I think if you look at the
telephones in a most enterprises of all sizes, they are still connected
either to a PBX or to the local operating company's switch. Clearly this is
not a huge growth market, but desk telephones are largely being replaced by
cell phones, NOT by VOIP or the like.
> And all of those real-time and synchronized applications working great, and
> outside the scope of 802. Which is (not coincidentally) one of my big
> questions about some of the work being investigated by this study group - why
> does 802 need to define isochronous services at all?
>
> People have been running real-time and synchronized applications over Ethernet
> for a long time. Timing issues are generally best addressed end-to-end at the
> application layer, and above L2. Not everything has to be addressed within
> 802.3.
First of all, while "real-time and synchronized applications" may be outside
the scope of 802, the services that enable the applications certainly are
not. The pushing of timing issues above L2 is not "generally" a good idea.
This is a tradition in the Ethernet/IP universe and has added a fair amount
of complexity and cost (and reduced performance) for *real* real-time
applications. For example, NO ONE runs a robotic system on an
*unconstrained* Ethernet.
And while it is certainly true that you can run real-time and synchronized
apps over Ethernet, the underlying network either has a constrained
environment (over-provisioning/topology limits with non-enforceable
admission controls -- like CobraNet), or "real-time" has been defined in
such a loose way that Ethernet will work. The objectives of this group
include a few interesting items that present interesting difficulties for
traditional approaches:
1) Round-trip delay times under 10ms, and
2) No loss of isochronous packets due to overloaded queues *anywhere in the
system*
3) Full support of worst-case spanning-tree topologies (I think that means 7
hops ... and yes, that does mean a new bridge).
Another item is "bridging of 1394 isochronous data", and the application
layers that use 1394 isochronous services expect similar levels of service.
> - Matt
>
--
---------------------------------------------------------------
Michael D. Johas Teener
http://public.xdi.org/=Michael.Johas.Teener - PGP ID 0x3179D202
--------------------- www.plumblinks.com ----------------------