|
Adisak,
Please see my comments below in green.
Regards, Siamack
Adisak Mekkittikul wrote:
See
my comment belowAdisak
Harmen,
Please see my comments below. Thanks for the interest.
Regards, Siamack
Harmen van As wrote:
Dear SiamackIt
would be necessary to back off your statements on the merits andperformance
of Open Loop with simulations.
> My statements are based on the protocol
flow charts & simulation of congestion avoidance algorithms conducted
so far. Please see slide #5 for the list of references.
[Adisak
Mekkittikul] which simulation? has anyone compared TCP fairness
performance
(fairness index) with DPT, iPT, etc. Has anyone shown how SLA
can
be met relying on TCP end-end flow control?
>>
[Siamack] As you may recall from my original email, my slides are for input
to the simulation work that is going on by various people. One baseline
comparison can be with congestion avoidance algorithm on or off (i.e. TCP
only, TCP + WRED etc.). In general it makes a lot of sense to have
an admin on/off switch for the CA algorithms and leave it to the service
provider to decide how to configure the network.
The goal of MAC protocolsis also to
achieve fairness among iinterfering nodes, not merely congestioncontrol.
> It would be helpful to have a concise
description of this goal, what is fairness in this context, and what
interference you have in mind. I have shown that CA algorithms covered
can introduce HOL blocking which is a form of interference. Open loop congestion
controls do not do this.
[Adisak
Mekkittikul] What are you smoking, As recent as this July meeting, I
presented
how to eliminate HoL blocking completely with VOQ.
The
goal is stated clearly "to achieve fair (weighted/equal) access to the
ring"
[Siamack] Adisak I
do not smoke. Your July presentation had the quiz which you have not solved.
That is the host throttling scenario. Other congestion avoidance algorithms
which do not maintain global state may suffer from station throttling.
So hopefully folks would show how their algorithms would perform.
What ever algorithm is short listed by the working group would have to
be rigorously tested via simulations and my presentation contains some
scenarios that the WG may want to adapt for these tests.
The goal of fairness in this context is equal access to excess bandwidth
on the ring. NOT
just access to the ring which can be achieved
through provisioning with no per station global state. IMHO maintaining
per station global state is too complex given the value that it adds to
the protocol. Latter is weighed fair access to excess bandwidth which
by definition is not provisioned and is best effort.
The first two statements on
CA mechanisms is certainly not true at all.
> Again the references in slide #5,
& existing simulations show that the weighted fairness algorithms are
only targetting the low priority class i.e. C' portion of the ring bandwidth
(C'= C-a ).
This is what I call static partitioning.
[Adisak
Mekkittikul] You are quoting things out of context again. In SLA based
network,
there is no such thing as a high priority traffic take away a committed
bandwidth
of low priority traffic.
I
suggest that we separate SLA based networks from the Internet of today.
However,
I'm not saying that all RPR vendors must build SLA capable equipment.
Choice
is up to each vendor. 802.17 MAC shall allow such implementation.
[Siamack]
Talk of out of context, I am not sure what you are talking about.
You seem to be going on a tangent here. I am not aware of any SLA
specifications in RPR WG. The proposals on the table discuss traffic
classes. There are some SLA specifications from IETF DiffServ effort,
but of course you want to keep away from Internet you say.
>The delay bound that I have in mind
is due to the high priority traffic class only. i.e. the ring access delay
of the high priority traffic is only due to high priority traffic on the
ring. In some CA schemes and under certain conditions described in the
slides, the low priority traffic is interfering with this bound. i.e. low
priority ring traffic is scheduled ahead of high priority acess.
[Adisak
Mekkittikul] Siamack, some parts of implementation are within the scope
of the MAC, some are outside (system issues). For example a line card designer
might
decide to implement multiple queues on his/her linecard to distribute access
delay to delay insensitive traffic. The list goes on and on
You
need to differentiate BW guarantee and delay guarantee. These are part
of SLA parameters
[Siamack] Look Adisak, my question is a simple
one. Does high priority add traffic waits for the low priority transit
packets to go through or not?
>Of course if one is patient enough
even best effort traffic would eventullay make it through. So we
have to be careful that we are on the same page with respect to delay bounds.
[Adisak
Mekkittikul] You don't understand TCP. Long delay can actually degrade
TCP performance. It'll slow down TCP rampup time (i.e, low throughput).
If
we are talking about 56Kbps, it's not a problem. But think about the future
that RPR will bring 10/100 Mbps or even 1G.
[Siamack] I was describing my definition of
delay bound. TCP's behavior with respect to round trip delays etc.
is well understood. High priority traffic should be treated so both
in transit and at add points to the ring. This would result in bounds that
can be calculated & controlled. If there is interference from low priority
ring traffic the problem becomes harder.
We will show that by two protocols
having different degrees of sophistication.Seems to become an interesting
and lively September meeting in San Jose.
[Adisak
Mekkittikul] I think this will be educational of most of us including me.
> Looking forward to it.
[Adisak
Mekkittikul] BTW, IEEE 802 standard does not
support only TCP/IP
An
IEEE 802.xx frame has to carry other types of protocol PDU too!
Here
goes your "open loop" (aka end-to-end closed loop) fairness.
[Siamack] 85% of Internet traffic is measured to
be TCP. It makes engineering sense to take this into consideration in the
design. I also recommend the admin. on/off switch. By the way what are
these other pdu types that you have in mind. Do you have any measurements
of what the traffic mix is?
Best regardsHarmen------------------------------------------------------------------
Prof.Dr. Harmen R. van As
Institute of Communication Networks
Head of Institute
Vienna University of Technology
Tel +43-1-58801-38800
Favoritenstrasse 9/388
Fax +43-1-58801-38898
A-1040 Vienna, Austria
http://www.ikn.tuwien.ac.at
email: Harmen.R.van-As@xxxxxxxxxxxx
------------------------------------------------------------------ORIGINAL
MESSAGETo: stds-802-17@xxxxxxxx
Subject:
[RPRWG] Merits of Open Loop
From: Siamack
Ayandeh <sayandeh@xxxxxxxxxx>
Date: Mon,
06 Aug 2001 11:01:39 -0400
CC: sayandeh@xxxxxxxxxx
Sender: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
Folks, As
some people are busy doing simulations and writing proposals for the
San Jose meeting, I am posting this
presentation early on the
reflector. It describes the
merits of open loop congestion controls and
may impact some of the simulation
scenarios that would be presented.
The main conclusions of the document
are that: - Congestion avoidance
algorithms may lead to static partitioning of the
ring bandwidth between high and low
priority traffic
- With CA it may not be possible to
bound the ring access delay of high
priority traffic
- Open loop does not suffer from HOL
blocking
- Open loop has relatively low configuration
and operational complexity
- Open loop is not prone to tuning
issues, or link aggregation, etc... Regards,
Siamack
|