| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Italo:
It is because peer MACs are standard compliant and the client is not.
As for a client, it is a matter of CPE/CLE equipment. The question is where is
the demarcation point. In any case it is in the client. Outside the MAC!
Harry
-----Original Message-----
From: Nader Vijeh [mailto:nader@xxxxxxxxxxxxxx]
Sent: Friday, March 29, 2002 12:48 PM
To: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
What is meant by "trusted" client? Is there a precedence for this concept in
802?
Can someone post the reference. Thanks.
Nader
-----Original Message-----
From: Busi, Italo /itah32 [mailto:Italo.Busi@xxxxxxxxxx]
Sent: Friday, March 29, 2002 12:08 AM
To: hpeng@xxxxxxxxxxxxxxxxxx; jalemon@xxxxxxxxx; raj@xxxxxxxxxxxx;
tripathi@xxxxxxxxxxxxx
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
I am amazed to see how much we trust our MAC peer (Km away from us) and
how much we do not trust our MAC client (few centimeters away from us)
;-)
> -----Original Message-----
> From: jalemon@xxxxxxxxx [mailto:jalemon@xxxxxxxxx]
> Sent: Thursday, March 28, 2002 6:43 PM
> To: tripathi@xxxxxxxxxxxxx; raj@xxxxxxxxxxxx; hpeng@xxxxxxxxxxxxxxxxxx
> Cc: jalemon@xxxxxxxxx; stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] RAH: Re: Minutes of Rate Ad Hoc meeting
>
>
> 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 -----
From: Devendra Tripathi
To: Raj Sharma ; 'Harry Peng'
Cc: stds-802-17@xxxxxxxx
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
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of
Raj Sharma
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
>
>