RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
See my comment in line
Italo
> -----Original Message-----
> From: pazy@xxxxxxxxxxxx [mailto:pazy@xxxxxxxxxxxx]
> Sent: Tuesday, March 19, 2002 3:55 PM
> To: jalemon@xxxxxxxxx
> Cc: pazy@xxxxxxxxxxxx; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
>
>
...
>
> 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.
>
As far as I know, metro netwoks are tipically made by many
interconnected rings (SBC made a good presentation in September about
this assumption).
This implies that you are loosing packets in the metro network so the
issue is not completely solved.
From the customer point of view there is no difference between loosing
packets on the ring or in the routers/bridges interconnecting rings.
The big difference is made by the amount of packets that the customer
sees as lost at end-to-end perspective ...
> 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
>
>
>
>
WINMAIL.DAT