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

Title: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
Raj,
 
The only reason I said  "Ignore reclaimability issue completely" is because it is causing so much confusion to everyone.   In that case, let me go back to your original argument -- "This implies that carriers would have to predict the levels of HP traffic in the network before they procure their equipment." 
I would say that they do not have to predict the HP traffic if part of the HP traffic is reclaimable and part of it is not.  That fraction is calculated based on your 2nd transit buffer size.  In this case, as a box vendor, your advertized feature may be a very large 2nd TB and consequently a large fraction of HP traffic is reclaimable.  This was in my january presentation.
 
However, the value of reclaiming unused bandwidth is very traffic dependent.  This regarding your comment about going back to SONET times!  Remember that we need to slowly ramp up traffic when the reclaimed bandwidth goes back to original HP traffic.  This is bad if the LP traffic pattern is ON-OFF, but may be OK if LP traffic is slowly varying.  So in fact, the way we are reclaiming bandwidth in RPR is not necessarily the best option.  Reservation could be just as good.
 
You say "The ad-hoc group last Tuesday agreed to a scheme to notify each node of the different HP reservation ratios on each span periodically. "
HP traffic should be provisioned by the operator if you are planning to support low-jitter services.  It is not something that will change by the second or minute.  If it changes due to the addition of a new node, etc. then it is sufficient to notify-on-change rather than periodically.  However that is again a provisioning / topology discovery issue that does not alter either the ring access scheduler or the fairness algorithm.
 
Vasan

-----Original Message-----
From: Raj Sharma [mailto:raj@xxxxxxxxxxxx]
Sent: Thursday, March 28, 2002 9:40 AM
To: Karighattam, Vasan; 'Raj Sharma'; 'Harry Peng'
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting

Vasan,
 
In a 2 transit queue system, as of now in the 802.17 proposal,
when LPTB become full. Neither can HP nor uncreclaimable traffic
get onto the ring - NO ONE BUT packet from LPTB can be sent to
the ring egress.
 
As a result there will be no traffic class with minimal Jitter.
Since, the only guarantees for jitter can be in the order of 2X RTT.
as opposed N X MTU (where N is the number of RPR nodes).
N X MTU << 2 X RTT (for say 2000 byte MTUs) 
 
Here is my response to your suggestions:
1. You say "Ignore reclaimability issue completely."
 
As you see from my discussion above the foremost issue is not reclaimability.
It is to avoid priority inversion that invalidates the smallest
delay one can get on the ring when another class simply tramples upon
this delay sensitive traffic because of inadequate buffer for a specific ring size.
Further, not being able to reclaim unused bandwidth takes us back to
SONET. Why reinvent the wheel when we cant come up with a better
invention !!
 
2. You say "ReserveBW on each segment."
 
Unfortunately, if the difference between the Reserved BW ratio on the ingress side
and the egress is huge - with egress side having say 80% reservation rate vs.. ingress
span having only 5% it further exasperates the situation.
 
The ad-hoc group last Tuesday agreed to a scheme to notify each node of
the different HP reservation ratios on each span periodically. I think this helps
AVOID both packet loss and priority inversion. I am just amazed at why such a
simple idea that solves such an incredibly valuable issue is an issue.
 
raj
 
-----Original Message-----
From: Karighattam, Vasan [mailto:vasan.karighattam@xxxxxxxxx]
Sent: Wednesday, March 27, 2002 5:58 PM
To: 'Raj Sharma'; 'Harry Peng'
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting

Raj,
 
>>So, the corollary, that if the LPTB size is fixed on the ring than for a given
>>ring circumference only a certain level of HP traffic, with absolute guarantees
>>on jitter, can be provided. This implies that carriers would have to predict
>>the levels of HP traffic in the network before they procure their equipment.
[Karighattam, Vasan] If you say that carriers will not like this, I think the correct solution would be to ignore the reclaimability issue completely.  So your reclaimable HP bandwidth is set ~0 (implies small or non existent 2nd TB).  Then reserve required bandwidth around each segment.  With the shapers at the output of each MAC, you will never need to suffer from priority inversion.  It also solves the scalability issue you have raised for 10G rings.  If not, the only useful size for the 2nd TB would be 2RTT!!
 
Vasan
 
 
 
 -----Original Message-----
From: Raj Sharma [mailto:raj@xxxxxxxxxxxx]
Sent: Wednesday, March 27, 2002 4:43 PM
To: 'Harry Peng'; Raj Sharma
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting

Harry,
 
I am not suggesting a lossy ring. I requested one, but most of you convinced
me that will never happen in RPR. So, I am moving on with an assumption of
a loss less RPR ring and I request you do too.
 
However, if I were to uphold the argument for a loss less ring while absolutely
guaranteeing no priority inversion than
a certain size of LPTB buffer must designed in. Obviously the size of this
LPTB depends on the levels of HP traffic and the RTT. Everything has a
consequence - there is no freee lunch !
 
So, the corollary, that if the LPTB size is fixed on the ring than for a given
ring circumference only a certain level of HP traffic, with absolute guarantees
on jitter, can be provided. This implies that carriers would have to predict
the levels of HP traffic in the network before they procure their equipment.
 
The one way to resolve this problem is to be able to "add" more LPTB
to the RPR MAC to sustain higher levels of HP traffic on the ring. Unfortunately,
at 10 gbps speeds off-chip TB schemes will have significant penalties.
 
Anyway, you missed my statement I made in the original email.
I said that if one were to prevent packet loss and avoid priority inversion
than one must AVOID situations that creates a scenario to pick one
over the other. Somehow, that seems like a simple logic to me. So,
my argument was not for supporting a lossy ring but what you need to
in order to have a loss less ring and avoid priority inversion.
 
In fact, I wonder why you don't think similar since your requirement is to
have a loss less ring, no priority inversion and a single 2 MTU TB. I would think
the a single TB with ability to buffer 2 packets cries out for some method
to AVOID a situation that will force priority inversion to honor a loss less ring
requirement. I must be missing something !
 
The real issue is that I am not fixated on preserving any implementation at
the cost of having an absurd standard. On the other hand, I am tolerant to the
big guns who want to do this I think we need to ensure that the RPR WG
do diligence.
 
raj
 
 
-----Original Message-----
From: Harry Peng [mailto:hpeng@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, March 26, 2002 7:40 AM
To: raj@xxxxxxxxxxxx
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting

Raj:

There are really two issues
one is vendor box issues when interworking:
1) utilization versus implementation to achieve the desired packet delivery behavior.
   The  1 TB and 2 TB design fall with in this category
   Once reserved BW is allocated globally or at link level, you think your box provide
   better ring BW utilization. All the power to you.


2) Lossy ring
   This is an 802.17 issue.
   Lossless behavior is a must. You are arguing for lossy.

Regards,

Harry
  
  


-----Original Message-----
From: Leon Bruckman [mailto:leonb@xxxxxxxxxxxxx]
Sent: Tuesday, March 26, 2002 1:59 AM
To: 'Raj Sharma'
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting



For the 2 transit buffer scheme there is another way:
Have a LPTB that is deep enough. The LPTB depth to avoid both: "on transit"
LP traffic discard and reduced HP priority, can be calculated using the
formula in:
http://grouper.ieee.org/groups/802/17/documents/presentations/jan2002/vk_dwd
el_02.pdf
This formula can be modified for the case of links with different reserved
rates also.

Leon

-----Original Message-----
From: Raj Sharma [mailto:raj@xxxxxxxxxxxx]
Sent: Tuesday, March 26, 2002 3:43 AM
To: 'Sanjay K. Agrawal'; Li Mo; stds-802-17@xxxxxxxx; Nader Vijeh
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting



The only way to guarantee HP traffic and have no packet loss
is to be able to AVOID situations that will reduce the priority
of HP traffic to satisfy a loss less ring.

There are two ways to avoid:
1. Provision the low priority to ramp-up very slowly - this
will result in low link utilization.
2. Constantly, provide each node the ability to determine
what conditions would lead to congestion.


raj


> -----Original Message-----
> From: Sanjay K. Agrawal [mailto:sagrawal@xxxxxxxxxxxxxxxxxx]
> Sent: Monday, March 25, 2002 5:03 PM
> To: Li Mo; stds-802-17@xxxxxxxx; Nader Vijeh
> Subject: Re: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
>
>
>
> For me 2 is very important otherwise I have very limited
> spatial reuse . On
> the other hand, allowing the packet loss on the ring, will
> limit the scope
> of this technology to TCP/IP networks. I think somehow we have to
> accommodate both.
>
> -Sanjay K. Agrawal
>
>
> ----- Original Message -----
> From: "Li Mo" <limo01@xxxxxxxxx>
> To: <stds-802-17@xxxxxxxx>; "Nader Vijeh" <nader@xxxxxxxxxxxxxx>
> Sent: Friday, March 22, 2002 11:04 AM
> Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
>
>
>
>
> I agree with the comments made by previous authers. I used to
> think one of
> the key characteristics of RPR is "no packet loss" once it is
> in transport.
> But, with the different reservation rate possible on
> different spans (unless
> a very sophasticated fairness algorithm has been used which
> is unknow at
> this time, this characteristics may be unattendable.  Hence
> we have a choice
> to be made:
>
> 1. allow the packet loss on the ring
> 2. allow different reserved rate on different span
>
> For those, I would like to see the first one unless somebody
> developed a
> fairness algorithm which achieves both.
>
> Li...
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Nader Vijeh
> Sent: Friday, March 22, 2002 12:12 PM
> To: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
>
>
>
> We have customers that find loosing packets in the transport
> side of the
> network unacceptable. One of the reasons we hear is the "multi-tier"
> environment, where the transport and the service side may be
> "logically"
> separate and belong to different business entities.  Another item to
> consider is that RPR is competing with SONET for the data transport
> infrastructure and SONET does not loose packets in transit.
>
> Nader
>
> -----Original Message-----
> From: Mike Takefman [mailto:tak@xxxxxxxxx]
> Sent: Friday, March 22, 2002 7:44 AM
> To: Italo.Busi@xxxxxxxxxx
> Cc: jalemon@xxxxxxxxx; pazy@xxxxxxxxxxxx; stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
>
>
>
> I beg to differ. We had presentations by Sprint at the working
> group that it is really important where packets get lost.
>
> Losing packet on the media is not acceptable to them.
>
> As I said previously, routers or switches tend to have
> buffers that are orders of magnitude larger than any
> buffer we are considering for the MAC. Therefore,
> loss probability is low at that level and they can engineer
> their network, (just like they would engineer the media)
> to get the loss statistics where they want them.
>
> cheers,
>
> mike
>
> Italo.Busi@xxxxxxxxxx wrote:
> >
> > 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
> > >
> > >
> > >
> > >
> >
> >
> --------------------------------------------------------------
> --------------
> ------------------------
> >                   Name: WINMAIL.DAT
> >    WINMAIL.DAT    Type: application/ms-tnef
> >               Encoding: base64
>
> --
> 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
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>