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

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
> 

WINMAIL.DAT