RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
John and others,
Maybe I should restate my views about configuration (by a user) Vs.
basic operation of a standard compliant devices.
I believe (but am not sure) that we essentially say almost the same,
where we might differ is the specifics of which points in the standard
should be directly open to user configuration. (As a side note: There is
a significant difference between options in the standard which allow
different vendors to implement different flavors of a given standard,
and flexibility in a standard which requires all vendors to support all
options and require a user interface to control these options).
I fully agree that the ring properties such as how much BW is allocated
to lossless, minimal jitter traffic (i.e. HP) Vs MP Vs LP, or how much
over subscription is allowed, etc. should be left to user specification
and the standard should not dictate this. I would think that such
configurations should better be left to the product themselves and not
be incorporated in the standard itself (because, for one, they are
tightly connected to size of buffers).
Having said that, I think that a standard should put some stake in the
ground English?) and not leave everything open. In this particular case,
I believe that all these behavioral parameters should be implemented in
the ingress points to the ring via policers/shapers and not by relying
on degree of loss on the wire itself. There we must have some consistent
model of behavior which will allow us to build all the other
specification, otherwise it's all become very open and fluid. I'm also
puzzled by how one would reason about such a ring. That is how can one
factor in the possibility of losing a packet in transit in some very low
probability and under very specific condition, in the overall parameters
of admittance to the ring?
Furthermore, if a user traffic is rejected at the ingress point, the
user gets an immediate feedback. Assuming such a feedback is useful, how
would a network do it if a given packet was dropped not at the ingress
but rather somewhere on the ring, say on the 5th node in a 10-node path.
Again, I hope that I've managed to clarify my views, but I am not sure
if we "violently agree" or still have some differences.
Offer Pazy
Burlington, MA
Tel: (781)359-9099 x1907
-----Original Message-----
From: John Lemon [mailto:jalemon@xxxxxxxxx]
Sent: Monday, March 18, 2002 8:43 PM
To: pazy@xxxxxxxxxxxx
Cc: stds-802-17@xxxxxxxx
Subject: 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