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

Raj,

You are scaring me again......

What ever happened to democracy and consensus???

Regards,

Harry

-----Original Message-----
From: Raj Sharma [mailto:raj@xxxxxxxxxxxx]
Sent: Monday, March 18, 2002 7:56 PM
To: 'pazy@xxxxxxxxxxxx'; 'Mike Takefman'; Yiming Yao
Cc: hans-j.reumerman@xxxxxxxxxxx; stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting

Offer, See my embedded comments, I feel we think very much alike:

> I fully concur with Mike's response. We have to be extremely careful
> about adding optional behavior (and variety) to the standard. In my
> opinion, we already have far too many options (for this early stage of
> the standard development). Options are a nightmare (and if someone can
> help me with a stronger word, please do :-) for users (carriers),
> testers, general audience, and finally to ourselves as we will have to
> work much harder to make all these options work together, are
> consistent, and that all combinations are covered. Additionally, there
> is the important issue of interoperability which is made exponentially
> more complex with each additional option.

You are right, Options will break a standard. Options will result in
having no standards. Having multiple ways of doing the same thing
is a cop-out. We should apply this to all aspects of the standard.

> From my experience, developers often tend to "be nice to users" by
> offering every options possible, just to later be rejected by the end
> users who don't have the infrastructure, the personnel, and the
> knowledge to sort out the options, to decide, to manage and
> to maintain
> their many network nodes.

You are right again !!
Imagine users who have pick RPR nodes based on number of transit paths.

> Specifically, please note that the packet loss we are considering here
> (or considering not allowing) is at the very low level of the physical
> level. Look at it as the property of the wire. And at some
> point we must
> establish a common model for this "wire" to be able to build the upper
> layers. This has nothing to do with the legitimate topic that is being
> discussed of policing traffic on the ingress points to the network.
> There of course, there are many tradeoffs that are better
> left of to the
> operators, and these tradeoffs are much more relevant to
> jitter, latency
> and the such.

Whether, the packet is lost on the "wire," as you mention, or in one of the
many buffers through which the packet has to pass through is after
the episode of loosing the user's packet. Loosing the packet on the
ring as opposed to loosing it at the ingress or egress ports offers very
little consolation to the user. However, not loosing packets, and yet having

infinite bandwidth along with jitter bounds sounds like another version of
he Brooklyn bridge sale! Most common people will stay clear of technologies
that can solve such paradoxes.

Once again I seem to be agreeing to you (it has become a pattern now !). The

"wire" must have a consistent model. It cannot exhibit "surprising"
characteristics
to its users - like suddenly changing the pre-established priorities of
access
to the ring.

> Offer Pazy
> 
> Burlington, MA
> Tel: (781)359-9099 x1907

 
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx] On Behalf Of
> Mike Takefman
> Sent: Monday, March 18, 2002 3:37 PM
> To: Yiming Yao
> Cc: '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
>