One way cable modems

[mcmanus at AppliedTheory.com (Patrick McManus)]

In a previous episode Jerry Feldman {75562} said...

:: For home based personal systems it works out. It provides a way for
:: the cable operator to offer the service before spending the bucks to
:: upgrade the entire network.  

it only sort of works out.. vast amounts of the potential is wasted
due to the hideous 1st hop latencies of POTS modems (often in the 3
digit ms range.. as opposed to sub 10ms times on bidirectional cable
modems).. at least in TCP environs this is true.

a normal client driven TCP connection is looking at 3 RTT of waiting (
syn-syn/ack request-responsestart fin-finack) as overhead.. for
something very common like a short HTTP transactions this overhead is
50% or more of the transaction and it is dictated by round trip time,
not simply downlink time.. so you're in a position where you can't do
*anything* in less than 1/2 of a second or so if you've got to
initiate a new connection[1] no matter how fast that downlink is.. and
you can feel the difference big time. (I've used the satellite version
of these)..

bigger downloads mitigate this somewhat of course.. but growing the
TCP window to adequately fill to the bandwidth*delay product of the
link (which is abnormally huge because of the fast recv path and the
slow ack) takes a number of round trips to do.. and those RTT have the
slow POTS in them again.. so you've got to get up to around 70KB
downloads to typically be using all that downstream bandwidth you've
bought. needless to say the vast majority of downloads (html,
gif/jpeg, mail messages, news articles) are no where near this
large.. and that's just the point where you start using all the
bandwidth available to you.. 

another, less publicized problem, is that of packet
retransmits.. when a packet has been lost and in the absence of
fast-recovery and fast-retransmit (which admittedly catch a lot of these
cases, but not all) a TCP timer has to elapse before the packet is
reset.. the size of that timer is based on your RTT.. so if fast
downstream packets are getting lost that is only going to be
determined at very long intervals more suited for dial sessions.. (say
3/4 of a second timeouts instead of 1/10 of a second timeouts).. this
can be a big deal.

it's pretty well understood now that TCP doesn't do well over
a-symmetric routing when those routes have very different
properties... this has some interesting QoS implications too.

-Patrick

--

[1] - HTTP/1.1 clients create less new connections than older HTTP/1.0
clients, but they still create a heck of a lot of them.. in these
kinds of environs running a local proxy that connects to a remote
proxy on the other side of the dial for all requests is a good
strategy as it basically allows all HTTP requests for all web sites to
be tunneled across this one pinned TCP connect and lets the handshakes
be done in a lower latency environ.. however idle periods do shrink
the TCP congestion window back down so you have to redo the growth cycle..

[2] http://rescomp.stanford.edu/~cheshire/rants/Latency.html
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).