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

Re: [RE] Stream identification at the MAC SAP



Fred:
Are you coming to the meeting because I believe you have nailed it?

John Gildred wrote:

 

Pioneer strongly agrees with this position.

-John Gildred
Vice President of Engineering
Pioneer Research Center USA
A Division of Pioneer Electronics
101 Metro Drive, Suite 264
San Jose, California 95110
(408) 437-1800 x105
(408) 437-1717 Fax
(510) 295-7770 Mobile

On Nov 12, 2004, at 1:04 PM, Tuck, Fred wrote:

> I don't think that when you are potentially running several 20MB/s HD
> video
> streams over your network and then someone wants to copy a DVD sized
> file
> from one computer to another that over-provisioning is going to be up
> to the
> task.  You can always find a way to saturate the network.  I believe
> that we
> need both QoS and reservation.
>
> Fred Tuck
> EchoStar.
>
> -----Original Message-----
> From: Gross, Kevin [mailto:kevin.gross@CIRRUS.COM]
> Sent: Friday, November 12, 2004 3:51 PM
> To: STDS-802-3-RE@listserv.ieee.org
> Subject: Re: [RE] Stream identification at the MAC SAP
>
>
> I believe that adequate QoS on a home scale network can be achieved
> easily
> with layer 2 protocols and over-provisioning.
>
> My arguments on this topic were not well received here.
>
> -----Original Message-----
> From: owner-stds-802-3-re@IEEE.ORG
> [mailto:owner-stds-802-3-re@IEEE.ORG] On
> Behalf Of Matt Squire
> Sent: Thursday, November 11, 2004 8:04 PM
> To: STDS-802-3-RE@listserv.ieee.org
> Subject: Re: [RE] Stream identification at the MAC SAP
>
>> 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.
>
> 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.
>
> - Matt