Re: CORRECTION Re: [EFM] EFM Requirements
Geoff Thompson wrote:
>
> Harry/Matt
>
> At 08:09 PM 8/20/01 -0400, Matt Squire wrote:
>
> > Harry Hvostov wrote:
> > >
> > > Matt,
> > >
> > > For the record, the actual stream transport for VoIP is done via
> > RTP/RTCP -
> > > application
> > > layer protocols. Needless to say, these protocols would rely on
> > the QoS
> > > mechanisms supported at L2/L3. For an example of mapping the MGCP
> > session
> > > descriptions into L2 QoS parameter
> > > sets please see PacketCable 1.0 Dynamic QoS specification at
> > > www.packetcable.com. The spec is publicly available.
> > >
> >
> > So what. At the Ethernet level a packet has priority.
>
> For the record: At the Ethernet level, a packet has NO priority.
>
> There is no mechanism to manipulate or order Priorities anywhere in
> 802.3
> There is a field allocated in the 802.1Q VLAN TAG that allows "user
> priority" information to be transported across Ethernet in an agreed
> upon location within a packet within a particular Ethernet protocol
> (802.1QTagType: 0x81-00)
>
> This information location of not normative in 802.3
> This information acted upon anywhere in 802.3
>
> This priority information is a feature of 802.1Q, not 802.3
> There are many other Ethernet protocols,each with their own
> identifying Type number. More than a few of them have a field for
> priority information. We (802.3) treat those protocols in exactly the
> same way that we treat packets of the 802.1Q protocol type, that is,
> we send them and receive them between the MAC Client and the medium on
> a first-in, first-out basis. That's all.
>
> Geoff
Hi Geoff -
I'm going to be different and not speak for the record.
I don't really disagree with anything you said. In its PAR, the group
had an explicit goal of conformance to 802.1Q. I really hope that this
means conformance to the user priority field in the Q header as the
method to obtain QoS in networks that use whatever comes out of this
group. Trying to do anything else would just screw up the hosts and
network equipment that has expectations on the behavior of switching
functions over Ethernet.
I realize priority is not normative in 802.3 or acted upon anywhere in
802.3. The Ethernet level is completelely application unaware and
priority unaware - that's my original point. At the switch level we
should be doing the same things that are done already - again completely
application unaware but priority aware - and outside the scope of this
group.
I think we're in agreement unless you are advocating some new QoS
abilities in EFM. Voice is no different then anything else.
- Matt