Please see my comments below. Thanks for the interest.
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?
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"
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.
>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
>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.
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.