Re: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
Offer,
As I mentioned in the Ad Hoc, and as Harry and Yiming have reiterated, there
are trade offs between utilization, delay/jitter, and loss. You can choose
at most 2 of the 3. I believe there is a general clear preference for lowest
loss most, then for lowest delay/jitter next, and then for highest
utilization of the available bandwidth last.
But Yiming's suggestion of allowing this to be configurable is intriguing.
While I believe we would always have the order I list above as the default,
I could imagine a customer wanting to change it away from the default. If it
were an option that they didn't have to configure, those that wanted to
change from the default would be accommodated; and those that didn't want to
be bothered with configing yet another parameter could safely ignore it.
John Lemon
----- Original Message -----
From: "Offer pazy" <pazy@xxxxxxxxxxxx>
To: "'Mike Takefman'" <tak@xxxxxxxxx>; "'Yiming Yao'" <YYao@xxxxxxxxxxxx>
Cc: <hans-j.reumerman@xxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
Sent: Monday, March 18, 2002 2:44 PM
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
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.
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.
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.
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