|
Dave, thank you for your response. The issue
that I would like to raise is far broader than this single case.
For all of our proposals we need to take a careful
look at the corner cases and make proposals in light of both "normal" operation,
and operation for the exceptional cases. My training has sensitized me to
always examine the extreme cases to make sure they do not break our
algorithms. In fact, most of the analysis and simulation required is the
hard job of looking at the corners after the relatively easy work of finding a
good solution for a normally operating network.
Best regards,
Robert D. Love Chair, Resilient Packet Ring Alliance President, LAN
Connect Consultants 7105 Leveret Circle Raleigh, NC
27615 Phone: 919 848-6773 Mobile: 919
810-7816 email: rdlove@xxxxxxxx
Fax: 208 978-1187
----- Original Message -----
Sent: Thursday, March 28, 2002 1:45
PM
Subject: RE: [RPRWG] RAH: Re: Minutes of
Rate Ad Hoc meeting
Bob,
I agree that the value of N*MTU was an
oversimplification
and the exact number will need to be derived before
we
are done. The wrapping scenerio is also important,
even
though glossed over for now.
DVJ
David V. James,
PhD
Chief Architect
Network Processing Solutions
Data Communications
Division
Cypress Semiconductor
110 Nortech Parkway
San Jose, CA
95134
Work: +1.408.942.2010
Cell: +1.650.954.6906
Fax:
+1.408.942.2099
Work: djz@xxxxxxxxxxx
Base: dvj@xxxxxxxxxxxx
David, I would contend that without wrapping or
steering, the formula for A should be (N-2)*MTU, since there is no jitter
associated with the sending or receiving station. However, the more
important case may be wrapping, rather than steering. Consider the
ring of stations A B C D E F with A sending to F the long way, and a break
occurring between E and F so that E wraps. The message goes from A via
the path A-B, B-C, C-D, D-E, E-D, D-C, C-B, B-A, A-F. In general the
maximum jitter can be (2N-3)*MTU.
In general, we need to make sure that we look
at the worst case conditions which are often not the normal ring operating
conditions.
Best regards,
Robert D. Love Chair, Resilient Packet Ring Alliance President,
LAN Connect Consultants 7105 Leveret Circle
Raleigh, NC 27615 Phone: 919 848-6773
Mobile: 919 810-7816 email: rdlove@xxxxxxxx
Fax: 208 978-1187
----- Original Message -----
Sent: Thursday, March 28, 2002 12:35
PM
Subject: RE: [RPRWG] RAH: Re: Minutes
of Rate Ad Hoc meeting
All,
Sorry for being a bit quiet recently, had a few
internal
tasks that popped up (I too have another
job!).
I think we have agreement on functionality but
some
conflicting visions of implementation
feasibility.
Let me try to summarize.
As to the desired client-visible
classes, these are
listed below:
Class
Jitter
Bandwidth
-------
------------- -----------
class-A ~N*MTU
jitter provisioned (up to 100%)
class-B
~RCT
provisioned (up to 100% minus class-A)
class-C
(unspecified) residual BW with
weighted fairness
Note:
N is the number of
stations
MTU is the maximum packet
size
RCT is the ringlet-circulation
time
Some folks have argued for a few more classes,
such
as A- and B+, or barely passing D
grades,
but these discussions should probably be
skipped
until we conclude on the basic definitions of
A,B,C.
The implementation concern is the techniques for
supporting
class-A traffic. Two techniques are
possible:
subclass-A0 - upstream
stations ensure provisioned rate
of idles for downstream station at all times
subclass-A1 - upstream stations ensure
provisioned rate
of idles for downstream stations, when
throttling is requested via flow-control signal
The key observations are
that:
a) the subclass-A1 traffic is
more efficient, because
temporal as well as
spatial reuse is possible.
b) the subclass-A1 traffic is more costly,
because
larger 2nd transit queue
sizes are needed.
c) the levels of supportable class-A1
traffic are dependent
on the ratio
of:
secondQueueDepth/linkLength
although the equation is
a bit more complex if the
queue depths
and link lengths are not all
the same.
What happens if
our station has a second transit queue,
that queue can only sustain 5% of subclass-A1
traffic, and
10% of class-A traffic is requested by the
client?
This is what happens when a MAC designed for Palo
Alto is
overextended to the Bay Area, for
example.
The answer is simple: the MAC provisions 5% of
subclass-A1
and 5% of subclass-A0 traffic, to meet the
cumulative 10%
class-A requirement. Thus, any second transit
queue design
can support 100% of class-A traffic, its just
that larger
amounts of
less-efficient subclass-A0 provisioning are used
when the queue-size is small and/or the
link-length is large.
There is also a secondary concern with regards to
management
of the secondary transit queue to sustain
downstream
demands for class-A traffic. I believe the basic
concept
in the current draft is OK, but refinements are
needed to
ensure successful operation. But, that's a topic
for another
day.
Again, I would like to emphasize deferral (not
cancellation)
of intermediate A- or B+ grades until convergence
on the
behavior and implementation of A0/1,B,C classes.
At that
time, their relative impact and benefits can be
better
evaluated.
DVJ
David V. James, PhD
Chief Architect
Network
Processing Solutions
Data Communications Division
Cypress
Semiconductor
110 Nortech Parkway
San Jose, CA 95134
Work:
+1.408.942.2010
Cell: +1.650.954.6906
Fax:
+1.408.942.2099
Work: djz@xxxxxxxxxxx
Base: dvj@xxxxxxxxxxxx
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
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
>
>
|