RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting

["Harry Peng"<hpeng@xxxxxxxxxxxxxxxxxx>]

Title: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting

 
Italo:

For compliance testing you need to define the value so it is measurable over a sample period.
What is the probability of loss in you model?

Your argument from "they do so why can't we is at best very weak".
Lastly, I blame Marc Holness for discussing brides. They are not part of the 802 last
time I checked. If you are looking for brides that is......

Regards,

Harry

-----Original Message-----
From: Busi, Italo /itah32 [mailto:Italo.Busi@xxxxxxxxxx]
Sent: Tuesday, March 19, 2002 2:50 AM
To: tak@xxxxxxxxx; YYao@xxxxxxxxxxxx
Cc: hans-j.reumerman@xxxxxxxxxxx; stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting

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
>