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



Harry,

what is the probability of loss in 802.1 bridges?

My argument from "they do so why can't we" is not meant to support 
packet loss as technically sound (I have other arguments for that), but 
to constrast the idea that allowing packet loss is making complaince 
testing unfeasible.
If 802.1 bridges support packet loss and can be tested for compliance, 
this means that RPR can be tested for compliance even if it eventually 
allows packet loss.

The goal of my mail was not to justify packet loss on the ring, but to 
free up the grond from what I think are wrong assumptions about 802 
compliance and compliance testing.

BTW, I was meaning "bridges" and not "brides" in my previous e-mail. 
All my previous arguments are applicable only to bridges and not to 
brides.
Sorry for the confusion ;-)

Italo

> -----Original Message-----
> From: hpeng@xxxxxxxxxxxxxxxxxx [mailto:hpeng@xxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, March 19, 2002 4:19 PM
> To: Italo.Busi@xxxxxxxxxx; tak@xxxxxxxxx; YYao@xxxxxxxxxxxx
> Cc: hpeng@xxxxxxxxxxxxxxxxxx; hans-j.reumerman@xxxxxxxxxxx;
> stds-802-17@xxxxxxxx
> Subject: 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
> > 
> 

WINMAIL.DAT