RE: EF% vs. BCN

[Raj Sharma <raj@xxxxxxxxxxxxxxxxxxxx>]

Title: RE: EF% vs. BCN

Hi Krishna,

 

EF traffic MUST NOT be shapped. This is mandated by Diffserv Per Hop Behavior PHB). Van Jacobson and Kathleen

Nicholson, amd Kedar Poduri have written an excellent IETF draft called "The Virtual Wire Behvaior Aggregate".

It is certainly more authoritative on the reaons.

 

Traditionally, when you provision services over a finite BW networks (finite BW networks have packet loss

above a certain cummulative ingress traffic at any given time) the BW available for statistical multiplexing

shoudl be reduced by total EF ingress BW provisioned through a network for EF PHB. Hence to have a

fixed and finite BW for other traffic EFshould be policed (rate limited) but never rate shapped.

Both AF and BE traffic can be traffic shapped on the other hand since BW management is done

by trading off latency (buffering) for throughput.

 

The crux of the discussion here is congestion management. The argumented presented is that if 

AF and BE  traffic is TCP in nature (it is mostly TCP but the purist would jump at me - hence I am

eliminating it from further debate as a basic premise in the argument) than it

will be under TCP flow control (end-to-end scheme based on window size parameter). Several

presentations made in the last 3 RPR meetings have proposed a node-to-node flow control.

This 2 feedback based control systems will interact. The issue is about consequence of such 

interaction on BW utilization. Let me explain the problem.

 

The egress scheduer on each Ring TX port will schedule EF as strict priority hence several nodes

downstream all the EF traffic accumulated from the nodes will sit in this priority queue and "bunch up".

 

If Node-to-node congestion is indicated during a stream of EF transmission than upstream nodes could

apply (W)RED to its AF and BE traffic sources to reduce the nodes contribution to congestion.

This will result in packet loss. The transmitting TCP sources will realise this and reduce its window

size (hence use less BW). However by the time the sources reduce theri rate the congestion at the node

maybe passed since EF traffic has been emptied. Now there is more BW available since the sources

have throttled themselves down. This will result inpoorer utilization of BW. The situation will detoriate further

due to statistical multiplexing.

 

Statistical multiplexing works because every (TCP) source does not emit packets synchronous

to each other. In fact, level of over-subscription is subject to such applciation and human layer

interactions. However, if the underlying protocols reduce this asynchronous nature and make traffic

more ordered than over subscription will be reduced. This is a fundamental issue that keeps the

internet alive today. However, the periodic nature of node-to-node flow controll will cause TCP

sources to all back up at the *same* time and retransmit at the *same* time and hence become

synchronized. 

 

As an example without node-to-node flow control and say ceratin network sees over larger time scales

a N-to-1 oversubcription would result is say 1% percent packet loss. This is considered in defining

a service providers revenue model of how many customer they can handle over their current network

capacity. Hence over-subscription is pre-planned by the service provider based on packet loss tolerance

of the services provided over TCP (or RTP). However when the TCP source get synchronized

and packet loss goes far above (1% in this example) the application "pain" thresholds then the

service provide will not be able to meet SLA aggrements with the customer and its too late reduce

over-subscription.

 

This issue has emerged often in link layer design in the past. ATM's ABR is a good example.

End-to-end flow control and intermediate node-to-node flow control will change the statistical

nature of traffic over an IP based network.

 

Some argue that node-to-node flow control is still required for traffic flows that do not have flow-control

at the layer 4. However, most of these have some form of notification schemes at the application layer

to indicate loss of reception. So, one still has 2 control systems interacting with non-deterministic

resluts. The other argument is that some source cannot be flow controlled due to its real time nature

and hence node-to-node flow control could apply to them. But, these are not AF or BE traffic they really

are EF traffic that have distinct bounds on burstiness and if they cannot be flow-controlled than node-to

node flow control will also have no affect.

 

raj

 

 

 

 

 

ginal Message-----
From: Krishna Pattabhiraman [mailto:Krishna@xxxxxxxxxxxxxxx]
Sent: Wednesday, August 30, 2000 9:06 AM
To: 'Raj Sharma'; Reflector RPRSG
Cc: 'Gunes Aybay'
Subject: RE: EF% vs. BCN

Hi Raj,

I fail to understand why you think that EF traffic cannot be shaped? Even the best of scheduler/rate controllers add at least a packet to the incoming burst length. So, if you do not shape the traffic on the way out, these bursts get accumulated and hence at hop h, you will see O(h) burst sizes even for EF traffic (which might have entered the network in a tdm/cbr manner). In such cases, buffer sizing for EF traffic has to take into account such bursts, else we'll notice pkt drops even for EF traffic (which is not preferrable).

 

The above burstiness was just due to the rate limiter at each input port. Now in addition to that, we might have "spatial" burstiness  - this adds a "fan-in" dimension to the burst. So, the "EF train" could grow to be a big one and rate limiters at downstream nodes may end up dropping them.

 

Regarding congestion indication - there is persistent congestion and then there is transient congestion - the congestion that you are talking about looks like transient congestion and should ideally be dealt locally (pick your flavor of RED) - congestion of persistent nature needs to be propagated back to upstream nodes (using BECN etc).

 

Krishna

-----Original Message-----
From: Raj Sharma [mailto:raj@xxxxxxxxxxxxxxxxxxxx]
Sent: Friday, August 18, 2000 7:00 PM
To: Reflector RPRSG
Cc: 'Gunes Aybay'
Subject: RE: EF% vs. BCN

Hi Gunes,

Maybe I failed to clarrify.

EF can be bursty data or constant bit rate source.
EF could be rate limited. Once admitted at the ingress
it assumes a very unique personality. In fact, it cannot be
shapped. As a matter of fact, most EF are more like TDM
traffic.
It has a specific queue treatment: it must be
sentout immediately without preempting the current packet
or getting preferential treatment over another EF packet
in the queue.
This preferential treatment gives it a "speedup" over other packets
and hence all packets will get clumped near a choke point At this choke
point the rest of the traffic has to wait till the "EF train"
passes through.

So, this would be similar to assesing traffic congestion by the average
wait time for cars on a road upstream from a railroad crossing.
The train always gets priority over the cars.

Which point in time will you pick to signal congestion?

-----Original Message-----
From: Gunes Aybay [mailto:gunes@xxxxxxxxxxxxxxxxx]
Sent: Friday, August 18, 2000 11:33 AM
To: Reflector RPRSG
Subject: Re: EF% vs. BCN

I don't necessarily agree that EF packets will be arriving together when
EF traffic is given
the highest priority. In practice, EF will be used for types of traffic that
require bandwidth,
latency and jitter guarantee, which are typical of voice and multimedia
applications. EF can
also be used to emulate TDM services over IP. By definiton, I would expect a
traffic class
that requires commited bandwidth and controlled jitter and latency not to exceed
the committed
rate. In any realistic implementation, the ingress devices would actually have
to do policing and
shaping with minimal burst allowance to enforce this kind of behavior,
otherwise, I cannot
see how EF can be made to work in any kind of network topology. If individual
EF traffic flows
are shaped so that they do not exhibit bursty behavior,  it would be reasonable
to expect that
aggregatetion of EF  traffic would also not exhibit bursty behavior .

I beleive a typical end-to-end EF deployment over an IP network would look like
this:

- Assignment to EF class would be subject to network level provisioning. The
provisioning
    system would have to know the total and currently utilized EF capacity for
each congestion
    point in the network.
- EF traffic will flows will be relatively  uniform (i.e. not burst) over time.
- EF traffic flows will be subject to admission control at the original ingress
point of the network.
    A policing based admission control scheme is OK for traffic that is not
inherently bursty, but
    a shaping function may have to be used for bursty flows. (I don't see why
one would map
    bursty flows into EF class, though)
- EF traffic will be subject to aggregate admission control at the admission
point to the ring. (It is
    easier to implement an aggregate shaping function at this point)

In such an implementation, I would expect to see the state of the high priority
queue used for EF to
be near-empty in a sustained fashion, i.e., if the total bandwidth allocated for
EF is less than
the ring

It is also  interesting to look at the implications of spatial reuse and
failover conditions on the
network level provisioning  mechanism that is used to manage EF traffic  in a
ring topology.

Gunes Aybay
RiverStone Networks