|
Devendra, just to fill in the stated hole in your
expertise, 802.5 does not allow a normally behaving station to lose a
frame. However, there are events, such as a station entering or leaving
the ring, which will "break" the ring for some number of milliseconds, at which
time any frames circulating on the ring will be lost. The loss of such
frames is considered an error condition. If a station does not receive its
transmitted frame back, it assumes that frame has been lost and then retransmits
that frame.
Best regards,
Robert D. Love President, 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 4:24
PM
Subject: [RPRWG] The loss less ring
MAC
Hi
Raj,
First of all I changed the subject as it was not reflecting the topic
well.
No I
did not mean that way (promiscuous-to-be-lossy-..), though it could have been
easly interpreted so. Also I find that comparing RPR MAC with 802.1 is
not fair (at least in as much as I understand the scope of 802.17 MAC). Also
no 802.3 MAC (that I know for sure), is specified to be lossy. That is just
not possible.
The
whole point is that of scope. Are we really looking for the MAC to have scope
similar to that of a bridge (I mean 802.1 like bridge) ? If that is the case,
I take my suggestion back. Please note that 802.3ad, even though has support
for many links (and priorities), it is not lossy. The reason is simply that
packets are expected to be buffered at highier layer.
So,
in summary, if we want to keep the theme of "MAC" similar to what has been in
802.3 (I do not know how it is in 802.5), then primary buffering
responsibility has to be shifted to highier layer. I like the idea of HP
traffic going through MAC itself, so you have much more deterministic control
over jitter but I would resist saying the same for LP as then you have to
decide between full buffering or lossy MAC.
Regards,
Devendra Tripathi
CoVisible Solutions,
Inc
(In India: VidyaWeb (India) Pvt Ltd)
90 Great Oaks Blvd #206
San
Jose, Ca 95119
Tel: (408)226-6800,
Fax: (408)226-6862
Devandra,
I
think I have been there before where you are headed.
I
call it "promiscuous-to-be-lossy-without-getting
into-trouble-because-everyone
will-forget-about-packets-in-wait" mode. But,
you will soon find out this mode violates 802.1
bridging rules and you will
labeled as the lossy-bigot :)
I
know it almost sounds like a secret religion !
I
agree with you that buffer size is not a scalable solution. However, we have
to
ensure that the single transit path based MAC is
not brain-dead.
I
have another suggestion for us to consider:
Let us completely eliminate any normative
statements in the standard that
RPR MAC must be loss less. Let us write an
informative section that shows
buffer recommendation guidelines and relate
this to ring size, node count and
levels of HP traffic in order to operate the ring
as a loss less ring. I have yet to
come across an IEEE MAC standard that actually
specifies a specific procedure
that one must perform "in the MAC" to ensure the
MAC is loss less. If someone
does find out please let us
know.
Further, lets us also move away from checking
against provisioning errors and
get into the argument that LPTB will fill
up when there is provisioning errors and in order to be loss
less
we
must check this every now and then. Since, I have also heard the
argument
that priority inversion will never happen in a
"properly" provisioned and configured
network. However, that is exactly what
the standard defines in the current TX algorithm.
We
cannot have split personalities. Either we design a
protocol that is designed for
error free operation when properly
provisioned and configured or we should be afraid
of every
conceivable provisioning error and have the
standard be made idiot-proof. Unfortunately, the later
will takes us into many more rat-holes and delay
the standard.
Your thoughts ?
raj
Hi team,
Looks if my response to Mike's earlier mail was not noticed as
everyone is talking about the deciding the buffer size to guarantee a loss
less ring. I would like to repeat the option I suggested in that mail.
Basically the packets which can not be delivered by MAC within a
certain time for a given priority could be sent to upper layer as "packets
in waiting". Since MAC can not be expected to maintains
flows, and out of order packets have to be avoided, once a packet of
a certain priority goes on the path of "packets in waiting", the MAC will
have to keep on sending all packets of that priority to upper layer till
"Waiting Queue Empty" indication comes from upper layer. Also, as I
mentioned in previous mail, it would be possible for a MAC to emulate the
behavior of this upper layer by having suitable size of buffer or allow
for loss, but then it would be implementation detail and standard would
not have to worry about it.
The buffer size option is not scalable one and it will be very
contentious issue (at least for a MAC).
Regards,
Devendra Tripathi
CoVisible Solutions,
Inc
(In India: VidyaWeb (India) Pvt Ltd)
90 Great Oaks Blvd
#206
San Jose, Ca 95119
Tel: (408)226-6800,
Fax: (408)226-6862
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
>
>
|