On Fri, 24 Dec 1999, Matthew Fredette wrote:

> my 3/60 gets its connectivity through a 33.6k modem, and the RFC
> describes "TCP extensions to improve performance over large
> bandwidth*delay product paths" - not what I have at all.

Would you say my 768kb/s DSL has a high bandwidth-delay product?  Surely,
we don't need fancy new RFC's for stupid technologies like old modems.
but...

I measured the delay to my first-hop router as the average of 32 ping
rtt's, and made the following table.

      bw kbits/s  delay ms   product
modem       33.6   214.252      7199 bits
DSL        768.0    17.960     13793 bits

so, the bw*d of DSL is not even twice that of a modem.  If I subscribed to
the cheaper 256kb/s service, the modem would have a higher bandwidth-delay
product, even when it's unloaded (ping).

However, unloaded b*d products aren't very interesting, because if there
is no load you don't care about bandwidth.  so, if you want to measure
delay to use in a b*d calculation, you should do it while your app is
running, after TCP congestion control ``settles'' (although, with
tail-drop queues, it doesn't), ex. after you're well into a big FTP
transfer.  What is the b*d experienced by the FTP session?

when you consider that modem output queues are almost always congested and
that modems have _gigantic_ output buffers (a buffer in the network code,
another in the serial port driver, and more (several?) in the modem for
the serial port and for V.42b), the typical rtt for a modem under load is
more like 1 - 5 seconds.  Knowing that you would not believe this either,
I started a single FTP transmission on the modem host and ran the test
again.  Averaged over 70 pings, I got

      bw kbits/s  delay      product
modem       33.6  2899.559     97425 bits
DSL          768    30.785     23642 bits

so the modem's b*d is four times greater under load.  and while the DSL
delay could be helped if my junky DSL bridge had an RED output queue (as
in ALTQ), the modem's queues exist mostly below the network layer and are
permanently hopeless.

the sort of thing they are talking about is how much data you send out
before it gets acknowledged-- the TCP ``window size.''

Don't fool yourself.  Modems have a _huge_ bandwidth-delay product.  i
have no idea what rfc1323 is or how it works, but if there's a problem
with using it, it's definitely not that your modem's bandwidth-delay
product is too small to make it worthwhile.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US