From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
> > Second, there is an easy, ad hoc QoS kludge in the radios that might
> > solve your initial timeout problem. Move IP packets carrying TCP
> > segments with the SYN bit set toward the front of the queue to ensure
> > that they are not delayed more than 2.5 seconds.
>
> doesn't help the IPSec crowd.
>
> does help the syn-flood attack script kiddies.
>
> doesn't help a saturated webserver that doesn't want to open or deal
> with new connections, but does want to service the ones it already
> has.
>
> doesn't do parallel UDP real-time streaming any good at all.
Since we were talking about text that talks about "2.5/3 Gen" radios
with queue latencies of 3 seconds, that list is almost entirely red
herrings.
- Help for paths limited to 10 kbit/sec dealing with any kind of
flooding attack is interesting, but not a relevant topic for the
text at hand.
- HTTP servers in the usual sense of the notion, saturated or not,
are unlikely to be behind 10 kbit/sec links.
- Parallel UDP real-time streaming sounds a rather unlikely over
10 kbit/sec radio modems to anyone who has ever actually used IP
over 9600 and 19200 bit/sec modems.
That leaves the difficulties with IPSec for the kludge as I described
it. However, the simpler kludge of moving to the front all packets
with at most 48 bytes of IP length and that are at least 2.5 seconds
old would work fine.
I still think the problem is not worth worrying about, because links
with 3 second delays are useless for the applications that the 2.5/3 Gen
mavens have been talking about.
Vernon Schryver vjs@rhyolite.com
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:28 EST