RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
This is very good point, I suggest, we should standardize such that the LP
packets which can not be sent on ring are pushed to higher layer (for
waiting), instead of discarding. The highier layer then can discard them,
based on some timer. Even if, in real implementation, the MACs emulate this
"highier layer" and discard the LP packets, it will not create a problem.
The standard has just to define that packets on local node interface can be
local node bound or packets in waiting.
Regards,
Devendra Tripathi
CoVisible Solutions, Inc
(In India: VidyaWeb (India) Pvt Ltd)
90 Great Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Fax: (408)226-6862
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Mike Takefman
Sent: Tuesday, March 19, 2002 11:12 AM
To: Italo.Busi@xxxxxxxxxx
Cc: YYao@xxxxxxxxxxxx; hans-j.reumerman@xxxxxxxxxxx;
stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
Italo,
the beauty of sponsor ballot is that you get to convince (or not)
people that your standard makes technical sense.
Just because something does not violate 802 principles does not
mean it is a good idea. I.E. Not violating 802 principles is
necessary but not sufficient. I would be interested to know how
many lossy MACs exist in the industry. I am not aware of any
MACs that provide loss, just switches or bridges. I would be
interested to find out.
I come from the school of though that the only place to be
dropping packets is above the MAC layer. This is because
above the MAC layer the amount of memory that you can
provide is orders of magnitude higher than in the MAC.
You have the ability to provide a single point of
policy, rather than worrying about N different points
of policy around the ring. And the size of the buffer can
be adjusted to provide whatever loss ratio people are interesting
in paying for.
With regard to "no other 802 MACs that have buffered packets",
there is an example in 802 already. See 802.12 R-MAC, not
that this proves anything one way or the other.
In the end Italo, we will have to agree to disagree, but given
that we are working in 802, allowing packet loss on the ring
IMHO is a guaranteed method to ensure that we never have a standard
pass ballot.
cheers,
mike
Italo.Busi@xxxxxxxxxx wrote:
>
> Mike,
>
> aren't we defining a new MAC? If yes, I think that we are free to do
> what it is the best for the problem we are trying to solve as long as
> we do not violate IEEE 802 architecture.
>
> There are absolutely no formal requirements that a MAC should be
> lossless. The only thing is that no MAC so far has been lossy.
> BUT, no MAC so far has defined the possibility to buffer frames
> nevertheless we are buffering in the MAC.
>
> Regarding compliance testing, the world is full of technologies that
> foresee packet drops. One straighforward example is 802.1D/Q brides and
> I am not aware of any issue about compliance testing.
>
> I would also add that "lossless" in 802.3 is not a feature but a
> LIMITATION. The market recognized that and left the shared medium
> paradigm in favor of a switching paradigm: Ethernet now is very popular
> for point-to-point full-duplex links interconnecting routers or LAN
> switches.
>
> Am I missing something?
>
> Thanks, Italo
>
> > -----Original Message-----
> > From: tak@xxxxxxxxx [mailto:tak@xxxxxxxxx]
> > Sent: Monday, March 18, 2002 9:37 PM
> > To: YYao@xxxxxxxxxxxx
> > Cc: tak@xxxxxxxxx; hans-j.reumerman@xxxxxxxxxxx; stds-802-17@xxxxxxxx
> > Subject: Re: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
> >
> >
> >
> > Yiming,
> >
> > speaking as a technical expert,
> >
> > while I understand your desire to have LP packets dropped, be aware
> > that 802 has never had a MAC that drops packets from the medium
> > except due to a CRC errors.
> >
> > From a compliance testing perspective, the issue of packet drops
> > would make it difficult (if not impossible) to provide a test
> > that proved compliance if packet drops were allowed. Remember,
> > if you can't test for compliance, it is not a standard.
> >
> > I believe that proper use of reserved BW will remove any need to
> > drop packets. I look forward to seeing the simulation results
> > that show problems as a part of the RAH.
> >
> >
> > mike
> >
> >
> > > Yiming Yao wrote:
> > >
> > > Hans,
> > >
> > > The current draft of the RPR standard tries to achieve
> > several objectives: high link utilization,
> > > guaranteed minimum jitter for reserved HP traffic, no
> > packet loss on the ring, etc, and these
> > > objectives are conflicting to each other sometimes. One
> > customer may want to disallow any LP
> > > packet drop on the ring even this means high jitter for the
> > HP traffic; another may want to
> > > guarantee minimum jitter to HP traffic (carrying TDM) at
> > risk of occasionally dropping some LP
> > > packets.
> > >
> > > My suggestion is that RPR provide a choice for the customer
> > to make his/her decision in conflict
> > > resolution.
> > >
> > > I didn't assume the operator wants to adjust the total
> > load/throughput. Maybe this can be done
> > > more easily if the above choice is provided.
> > >
> > > Regards,
> > >
> > > Yiming
> > >
> > > -----Original Message-----
> > > From: hans-j.reumerman@xxxxxxxxxxx
> > [mailto:hans-j.reumerman@xxxxxxxxxxx]
> > > Sent: Friday, March 15, 2002 1:35 AM
> > > To: stds-802-17@xxxxxxxx
> > > Subject: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
> > >
> > > > Yiming Yao: allow customer to choose between loss,
> > jitter, and utilization
> > >
> > > Is the underlying assumption that the operator of the
> > ring (=customer?) wants to
> > > adjust the total load/throughput? Would this be for
> > loadbalancing purposes?
> > >
> > > regards,
> > > Hans
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Hans-Jürgen Reumerman
> > > Hans-J.Reumerman@xxxxxxxxxxx
> > > Digital Communications & networking
> > pww.pfa.research.philips.com/dc/
> > > Philips Research Laboratories
> > Phone: +49 241 6003 629
> > > Weisshausstr.2, 52066 Aachen, Germany Fax:
> > +49 241 6003 519
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > --
> > Michael Takefman tak@xxxxxxxxx
> > Manager of Engineering, Cisco Systems
> > Chair IEEE 802.17 Stds WG
> > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > voice: 613-254-3399 fax: 613-254-4867
> >
>
> ------------------------------------------------------------------------
----------------------------
> Name: WINMAIL.DAT
> WINMAIL.DAT Type: application/ms-tnef
> Encoding: base64
--
Michael Takefman tak@xxxxxxxxx
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 fax: 613-254-4867