In order to make use of the ECN, support from
the transport protocol is needed. For TCP three
additional functions are identified: i) negotiation
between the end-points during connection estab-
lishment to decide whether or not they are ECN-
capable; ii) an ECN echo flag in the TCP header
informing the sender that a CE-marked packet
has been received (bit 9 in the Reserved field of
the TCP header); and iii) a Congestion window
reduced flag in the TCP header allowing the
sender to inform the receiver that the congestion
window has been reduced (bit 8 in the Reserved
field of the TCP header).
The sequence of messages related to ECN is
illustrated in Figure 9.
TCP should not react on congestion indications
more than once every congestion/acknowledge-
ment window (or about once every round-trip
time). That is, a sender should not reduce its
congestion window more than once in response
to a message dropped and/or packets having the
CE bit set out of a single window. It is stated
that the ECT bit should not be set for pure TCP-
ACK messages as no flow control is related to
such messages. The same goes for TCP window
probing, that is for packets generated periodi-
cally by the sender when the receiver has
announced a zero window. As explained in
[ID_tcpecn] nor should the ECT bit be set on
retransmitted packets. Furthermore, the receiver
should ignore the ECN field on the out-of-win-
dow data packets. Both these means are intro-
duced to increase the security against denial-of-
service attacks, i.e. where an attacker may spoof
the IP source address and send packets making
the receiver asking the real sender to decrease
its sending rate.
For the moment, no special concerns are given
when ECN is used within MPLS or other layer
2 transport means. For other ways of tunnelling,
i.e. IP in IP, two options have been described:
- Full-functionality where the ECT bit of the
inner header is copied to the outer header.
At decapsulation, if the ECT bit of the inner
header is set, the CE bit of the outer header
is ORed with the CE bit of the inner header
to update the CE bit of the inner header. - Limited-functionality when ECN is not used
for the IP tunnel. This is done by turning off
the ECT bit of the outer header and not alter-
ing the inner header.
2.3 Scheduling
When implementing a network offering different
traffic classes, queueing and scheduling mecha-
nisms have to be configured. The choice of the
better mechanism to use to obtain the declared
service differentiation is far from obvious. This
is one of the reasons for vendors to implement
a variety of different queuing and scheduling
mechanisms. As an example a few of the differ-
ent mechanisms found in the Cisco routers are:- Modified Deficit Round Robin (MDRR):
MDRR may be able to provide special support
for delay sensitive traffic, such as Voice-over-
IP. MDRR includes a low-latency, high-prior-
ity queue that is treated differently from the
other queues. This special queue is used to
handle delay-sensitive traffic. It is possible to
configure MDRR for strict priority handling
of this queue. When that queue contains pack-
ets, it is served first until all of its packets are
sent. Within MDRR, IP packets are mapped
to different class-of-service queues, e.g. based
on precedence bits (part of the ToS field). The
remaining queues are served in a round-robin
fashion. - Weighted Round Robin (WRR): WRR is a
packet queuing and scheduling algorithm,
which provides class differentiation, band-
width allocation, and delay bounding features.
Hence, it is possible to give voice packets pre-
mium service, although not strict priority. - Weighted Fair Queuing (WFQ): WFQ is an
algorithm that provides priority management,
but not strict prioritisation, during periods of
traffic congestion. WFQ offers a solution that
provides consistent, fair response time, based
on weights. Hence, WFQ supports features
such as traffic isolation and delay bandwidth
guarantees.
A second type of WFQ called Distributed
Weighted Fair Queuing (DWFQ) provides
bandwidth allocations and delay bounds to
specified traffic flows by segregating the traf-
fic into classes and then using first-in, first-out
(FIFO) service to the various queues accord-
ing to their assigned weights. There seems to
be two kinds of standard WFQ (Flow-based
WFQ, Class-based Weighted Fair Queuing,
CBWFQ) and three kinds of DWFQ (Flow-
based DWFQ, QoS Group-based DWFQ,
ToS-based DWFQ) implemented in the Cisco
routers.- Internet Protocol Real-Time Transport Proto-
col Priority (IP RTP Priority): With the IP
RTP Priority feature it is possible to specify a
range of UDP/RTP ports whose traffic flows
receive strict priority service over any other
queues or classes. Strict priority means that if
packets exist in the priority queue, they are
fetched from the queue and sent first.