|
Siamack,
No minutes were really necessary. The contents of
the discussions were mostly contained to the presentations from John Lemon,
Harry Peng, and Necdet Uzun. (There was also a presentation submitted by David
James that we didn't have time to review.) We saw that we are
converging towards saying the same things. Pretty much all there is to
say.
jl
----- Original Message -----
Sent: Thursday, March 28, 2002 10:42
AM
Subject: Re: [RPRWG] RAH: Re: Minutes of
Rate Ad Hoc meeting
Members of the RAH,
It is interesting that a thread with subject "minutes of the RAH meeting"
is still circulating on the RPR-WG mailing list, but no one actually bothered
to take any minutes for the 3/26 meeting!
Could some one please summarize what happened.
Thanks, Siamack
John Lemon wrote:
Devendra, In order to do this, one would have to have a
*very* trusted client, which has not been an assumption in past MAC
standards. I would argue that either clients are completely trustworthy and
you allow them to flow control and rate shape all traffic, or clients are
not completely trustworthy and you never allow them to touch a packet not
destined for them. I don't see any point in-between. Frankly, while allowing
clients to interact with the transit path is intriguing from an engineering
point of view, I doubt it would be acceptable to many
people. jl
----- Original Message -----
Sent: Wednesday, March 27, 2002 5:22
PM
Subject: RE: [RPRWG] RAH: Re: Minutes
of Rate Ad Hoc meeting 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
convincedme that will never happen in RPR. So, I am moving on with an
assumption ofa 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
thana certain size of LPTB
buffer must designed in. Obviously the size of
thisLPTB depends on the levels
of HP traffic and the RTT. Everything has
aconsequence - there is no
freee lunch !So, the corollary, that if
the LPTB size is fixed on the ring than for a
givenring circumference only a
certain level of HP traffic, with absolute
guarantees on jitter, can be provided. This implies that carriers would
have to predictthe 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 inversionthan one must AVOID situations that creates a scenario to pick
oneover 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
toin 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
tohave a loss less ring, no
priority inversion and a single 2 MTU TB. I would
thinkthe a single TB with
ability to buffer 2 packets cries out for some
methodto AVOID a situation that
will force priority inversion to honor a loss less
ringrequirement. I must be
missing something !The real issue is that I am
not fixated on preserving any implementation
atthe cost of having an
absurd standard. On the other hand, I am tolerant to
thebig guns who want to do
this I think we need to ensure that the RPR
WGdo
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
>
>
|