Port numbers and traffic data

[Ian Batten]

On 22 Apr 2008, at 15:33, Brian Morrison wrote:
>
> Well, at 50:1 contention levels, you'd need incredible amounts of  
> buffering to cope

Long term, obviously.  The last time I looked at statistics from real  
networks, admittedly pre-iPlayer, most backhaul circuits over went  
into overload in very brief bursts, where buffering might be enough to  
help.

> (something that ATM traditionally doesn't do much of in BT's case)  
> and that wouldn't help if contention is continual instead of bursty.  
> Better to let the TCP layer retry I suppose,

But that they depends on how you implement, say, random early drop,  
which is exacerbated by the downstream being ATM as well.  It's a long  
time since I worked on this, but my memory is the problem is that if  
you start dropping cells on the backhaul, you almost immediately hit  
the situation where throughput is saturated but goodput is zero.

That's because if you simply drop cells at random to police it into  
the available bandwidth, the chances are that you transmit a lot of  
broken IP frames (you can model the goodput of frames which consist of  
more than one cell in the face of dropping cells, and it's not  
pretty).  What you want to do is to drop complete IP frames or  
transmit complete IP frames, as that way goodput stays high (or at  
least non-zero).  The classic solution to this is random early drop:  
under load, drop incoming frames so that you can process and ship  
complete, good frames.  This is harder in a DSLAM, because it never  
sees IP qua IP: it's doing raw ATM which happens to be PPPoA, so the  
effects of dropping cells are unpleasant.  I'll ask one of our traffic  
engineers tomorrow, but my memory is that there are approaches  
available in our switch which mean that under load most of the cells  
shipped upstream are part of complete IP frames; sadly I can't recall  
the details.

> assuming that more bandwidth is impossible (and it seems to be).

Not impossible; expensive.

ian