[Iccrg] draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

[Bob Briscoe]

Dimitri,

At 23:45 07/08/2007, dimitri papadimitriou wrote:
>>Also:
>>- Is a good system & equipment design goal to sacrificially throttle 
>>bit-rate to avoid CPU overload (so the brain can still work out what to 
>>do about congestion)?
>
>what do you mean with "sacrificially throttle" ?

I guess I didn't explain myself well. We'd like researchers not to have to 
think up alternaitves to smart congestion control (e.g. XCP or even AQM) 
that achieve the same effect, but can be implemented in cheap, lower layer 
equipment. The research issue is whether we will be able to rely on the 
same 'sacrifical throttling' as we do now to avoid this issue.

Example 1/ A route lookup engine requires a certain min amount of time to 
do the most complex address lookup. Usually the line feeding a route lookup 
processor is sized so that even a stream of the smallest possible packets, 
with the lowest possible cache hit rate, couldn't arrive at the route 
lookup engine faster than it could look-up the addresses. In this case, the 
bit rate of the line is sized to effectively sacrifically throwing away 
excess packets to protect the route lookup processor.

Example 2/ Even if all the L3 routers feeding into the L2 network were 
outputting at line rate and the traffic matrix was the worst possible - all 
converging on the lowest capacity L2 switch - the capacities could be 
arranged so that any L2 switch could not ever be overloaded (aside from 
failures). Then if the operator wants everything to do AQM or ECN or 
something, only the L3 routers need to do AQM. The L2 switches don't have 
to have any AQM code, because they will 'never' get overloaded. So the L3 
routers are effectively sacrifically throttling traffic on behalf of the L2 
network.

Example 3/ A single transmission line is actually a degenerate case of both 
the above examples, where the queue feeding the line sacrificially 
throttles traffic so that the line doesn't have to discard excess traffic 
at the phy layer (where the analogue signal would screw up, instead of the 
queue discarding whole packets). However, this is an example where a 
processor is protecting a phys component, rather than the other way round.

My point was simply that we should be able to rely on sensible system 
design and not have to say that deploying smarts at all layers is a 
research issue. But, for the resons below (about packet sizes), we might 
have to worry about how to put smarts in lower layers as well.


>>- distinguishing per-packet congestion from per-byte congestion (similar 
>>problem to distinguishing congestion from wireless transmission losses)?
>
>you made that comment during the "corruption loss" discussion, do you see 
>this as a separate discussion point now ? note also relationship with the 
>packet size (former).

It's a separate discussion point. It just has strong parallels with the 
corruption loss issue (ie a solution to one might solve the other).


>>- ever-widening range of packet sizes: if design equipment for larger ave 
>>pkt size, gets overloaded with flurries of small packets.
>
>you made that comment during the "small packet size" discussion -> i
>guess this would like to see a discussion about impact wrt relative avg 
>size and range ?

Yup. Ideally as links get faster, we'd like to only have to deal with 
larger packets, but we're never going to be able to have a flag day 
stopping people sending smaller packets (partly because there will always 
be slower links connected to faster links in the Internet).

This is likely to become a big issue in the future when considered against 
the first point about sacrifical protection of processors by bit rate 
throttles: packet header processors will always have to be able to handle 
streams of packets with 0byte payloads.

Currently, we tend to assume congestion is by bits. But these worrying 
thoughts imply we could start to see more per-packet congestion appearing 
alongside per-bit congestion. That complicates matters greatly.

Background to this issue is discussed in 
draft-briscoe-tsvwg-byte-packet-marking-00.txt that I recently posted. But 
that I-D only hints at the 'sky is falling' thoughts of this email.

Cheers



Bob


____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196