[e2e] TCP, retransmissions, and ISPs with byte caps

Philippe Strauss philou at philou.ch
Tue Jun 18 08:34:19 PDT 2002


On Tue, Jun 18, 2002 at 08:57:18AM -0400, David P. Reed wrote:
> At 08:17 AM 6/18/2002 +0200, Philippe Strauss wrote:
> >But about delays, CATV systems have an interesting characeristic:
> >a ~20ms minimum delay in the ACK path (direction from home
> >to the hub, upstream or return path in catv speak).
> 
> I have been pinging various targets through my LANCity cable modem for 
> years now and I have regularly gotten 7 msec. ping RTT to lcs.mit.edu which 
> is a few hops (11 at the moment) away.  This morning the average is 13 
> ms.   Where's the 20ms minimum?   How did you determine it?
> 
> Perhaps you meant 20 *micro* seconds?
> 
> Or maybe Swiss cable systems are really really slow.

hehe, no, but since CATV based internet is still young,
there are very differents technologies in the field.

old and simple: zenith equipement, a simple modulation
scheme (4PSK), very low delay (hundreds of nsec), but an horrible behaviour
on noisy return path plant.
return path access was managed by... CSMA/CD of your ethernet adapter.

then came the LANcity. my colleagues tried it and shipped it back due
to a terribly long time for the modem to reconnect after
a plant outage or noise burst (several hours for ~ 500 modems)
modulation and access to the return path was close to the docsis1.0
standard I think.

terayon and it's teracomm 1000, a well designed system on
the transission side: spread spectrum CDMA, good performance even
on noisy plant. 
it's allocation scheme on the upstream path, most of the time,
impose a 20ms min RTT for the basic UBR traffic contracts.
with a non UBR you get better RTT, same values as you
see with the LANcity.
there's also forward error correction code, but
taking some hundreds of us, not miliseconds.

Docsis 2.0, merging the teray CDMA based transmission in the
Docsis 1.1 framework.
I don't know much about RTT achievable with Docsis1.1.

I have seen strange congestion situation leading me to think
this high (20ms) RTT was causing TCP global synchronization,
but never at a time where I was a the right place
to run a tcpdump (situation like: duh it drop packets like heavily congested
while 5min avergage shows 70% usage and noise level seems ok).

regards.

-- 
Philippe Strauss
http://philou.ch/

L'indifférence est le plus grand risque de notre temps,
la forme civilisée de la cruauté.  -- Zenta Maurina
--




More information about the end2end-interest mailing list