المساعد الشخصي الرقمي

مشاهدة النسخة كاملة : Flames And Recurring Holy Wars



A7med Baraka
04-15-2009, 08:55 PM
As with any News and/or email list, topics will be raised which
elicit a broad range of viewpoints. Often these are quite polarized and yield
a chain of replies and counter topics which can span weeks and even months.
Typically without resolution or group consensus. This section lists some
memorable (lengthy?) topic threads.

PLEASE NOTE that the idea here is not to re-kindle old flames, and not to
somehow pronounce some conclusion. Rather, recorded here are are a few
pieces of the dialogue containing information which might be of some use.


SUBJECT: G1) Are big buffers in ATM switches needed to support TCP/IP?

A recurring theme in 1993 concerned the suitability of ATM to
transport TCP/IP based traffic. The arguments generally centered around the
possible need for ATM WAN switches to support very large buffers such that
TCP's reactive congestion control mechanism will work. Points of contention
include: are big buffers needed, if so then where, and what exactly is the
TCP congestion control mechanism.

Undoubtedly, many of these discussions have been fueled by some 1993 studies
which reported that TCP works poorly over ATM because of the cell-discard
phenomenon coupled with TCP's congestion control scheme.

The longest thread on this subject started in the October 1993 timeframe and
ended in December under the subject of "Fairness on ATM Networks".
Generally folks expressed opinions in one of the following postures:

1) Big buffers are not needed at all....

A few argued that if ATM VC's are provisioned and treated as fixed leased
lines then ATM will be able to support TCP/IP just fine. This means that
you would need to subscribe to the maximum possible burst rate which would
be very inefficient use of bandwidth since TCP is usually very bursty.

2) Put big buffers in routers and not ATM switches....

If you are using wide-area links over ATM, then use a router smart enough
not to violate the Call-Acceptance contract. The call acceptance function
should be such that it doesn't let you negotiate a contract that causes
congestion. Congestion should only occur when there is a fault in the
network. A router is quite capable of smoothing out bursts. That is what
they do right now when they operate over leased lines. The advantage of
an ATM connection replacing a leased line is that the connection parameters
can be able to be renegotiated on the fly, so if your IP network (as
opposed to the ATM network) is experiencing congestion, then it can request
more bandwidth.

Supporting this thinking is the notion that for most data networks using ATM
as their wide-area medium, a router would likely be the access point with
many TCP connections being concentrated on a given ATM connection.

3) Still others suggest that ATM switches should implement priorities and
that there should be different buffer sizes allocated per priority.
The different priorities and associated buffer sizes would support
traffic separation, trading off cell loss for delay. So for example,
"voice" traffic could have small buffer sizes and "data" traffic could
have big buffer sizes. The switches would then provide the buffering
necessary to support TCP's reactive congestion control algorithms.

Some folks argued that this would be "expensive" to implement. Regardless,
many new switches being anounced in 1993/4 claim to have such priorities
and buffer size capabilities.

Finally many folks were not clear on the differing TCP reactive congestion
control mechanisms. A quick summary follows:

In the original algorithm, the TCP goes into slow-start when a packet loss
is detected. In slow-start, the window is set to one packet and increased
by one for every acknowledgement received until the window size is half what it
was before the packet is dropped. You get a series of larger and larger
bursts but the largest causes half the number of packets to be buffered as
there were before the packet drop occurred. Hence there is no burst until the
window size is half what it was before the packet is dropped and is then
increased at a much lower rate, 1/(window size) for each acknowledgement.
This window control algorithm ensures that the only bursts generated are
probably small enough to be no problem.

In the Reno algorithm, the window is halved so that packets start being sent
in response to acknowledgements again after half the old window's of
acknowledgements have been received. Hence there is no "burst" of packets
generated. The only packess generated are in response to acknowledgements,
and only after half an old window of acknowledgements are received.

For more information check out Van Jacoboson's algorithms published in
ACM SIGCOMM 1988.


SUBJECT: G2) Can AAL5 be used for connection-less protocols?

This thread started with questions about wether AAL5 supports
connection oriented or connection-less protocols. Check the November
and December 1993 archives for the subject: "AAL Type 5 question".

First some background
---------------------
Officially, AAL 5 provides support for adaption of higher layer connection-
oriented protocols to the connection-oriented ATM protocol.
There was, however, a debate going on, claiming, that AAL 5 could also be
used to adapt higher layer connectionless protocols to the connection-oriented
ATM protocol.

The whole debate is grounded in a systematical approach of the ITU-T, which
states, that all AALs should be classified into four different classes, to
minimise the number of AALs required for supporting any imaginable service.

The classification of the ITU-T is as follows:

+------------------------+-----------+-----------+-----------+-----------+
| | Class A | Class B | Class C | Class D |
+------------------------+-----------+-----------+-----------------------+
|Timing relation between | Required | Not Required |
|source and destination | | |
+------------------------+-----------+-----------+-----------------------+
| Bit Rate | Constant | Variable |
+------------------------+-----------+-----------------------+-----------+
| Connection Mode | Connection-Oriented |Connection-|
| | | less |
+------------------------+-----------------------------------+-----------+

AAL 5 is currently agreed to be in Class C. Some parties at the
standardisation bodies claim that it could be as well in Class D.

At the moment the following mapping between AALs and classes applies:
Class A: AAL 1
Class B: AAL 2
Class C: AAL 3/4, AAL 5
Class D: AAL 3/4

The reason for AAL3/4 in classes C and D is the follwing:
The ITU-T started to define AAL3 for Class C and AAL 4 for Class D. They
turned out to be identical after long debates.

Reality Check
-------------
The real issue is how to run a connection-less service over ATM which is
inherently connection-oriented. AALs themselfs merely transport higher
layer packets across an ATM virtual circuit. Connection-less services
are actually provided by higher layer protocols such as CLNAP. Given
that, there is nothing to prevent folks from using AAL5 to implement
a connection-less communication mode. This is exactly what the IETF is
doing with IP over ATM, and what the ATM Forum is also doing with
LAN Emulation.

The reality is that these folks expect that AAL5 will be largely used for
connection-less upper layer protocols such as CLNP and IP. So some
find it strange to have AAL5 classified as an AAL for connection-
oriented services only.

However, from an ITU-T service Class perspective, you must stick strictly to
the view that to call an AAL "Class D" it must support each and every
posssible connection-less protocol. The current agreement in the ITU-T
is that AAL5 can not claim this and so is officially considered a
"Class C" AAL.