In message <[email protected]>, Eric Travi
s writes:
>
[...]
> : bypasses TCP congestion control. This is not so bad with a private
> : network where other methods of congestion control can be implemented.
> : But, if this does start showing up in the Internet, it might cause a lot
> : of problems. I guess I am just offering this up as another reason
> : why we need to solve some of the perceived TCP problems related to long
> : delay paths...
>
> I also encounter, on a regular basis, folks that seriously consider
> UDP-based approaches. For me, this is currently within a NASA domain
> (but not all of NASA will agree with my position on this), but it was
> also a regular thing with DoD and commercial sponsors too.
At least one vendor has SFQ and WFQ in the forwarding hardware on a
subset of their forwarding cards which means that it can be enabled in
moderately fast interfaces. What would really be needed is two stage
hash SFQ such that a greedy hash bucket could be more finely split if
it continues to grow despite RED's efforts.
If this practice becomes widespread there is a cure. Until it becomes
widespread a few ignorant and/or sleezy vendors may ignore the need
for congestion avoidance in commercial products.
With SFQ you just hurt yourself by not implementing congestion
avoidance. I'd personally rather prevent the problem than cure it but
vendors are not moving quickly on this because SFQ has nonzero
development costs when it needs to go into an ASIC.
Curtis
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:39 EST