Subject: Re: When non TCP/IP literate people design cable modem systems

From: Sean Doran <[email-masked]>
Date: Thu, 24 Jun 1999 02:41:38 +0200 (CEST)

| Within bound, I do actaully think there are good justification for link
| layer retransmission.  When I am in a hotel sitting in front of a crappy
| phone line, it is better to have the terminal server's modem retry
| (LAPM) a few times instead of having the retries to be all done
| end2end.  

Yeah, and when the path between my Ciena transponder's optics 
and those on my Cisco box is slightly messy, I'd really feel more
comfortable with LAPB running to make sure no important packets
are lost and have to be retransmitted by the source.

As to RTT estimates being messed up -- well, RFC 2001 is deeply 
spooky and everyone will be much happier when congestion is prevented
by controlling the rate at which the edges of the network can send,
because then we can just ignore all the error-prone timer stuff we
see crop up all the time in TCPIMPL.  We can even smooth out those
short-term traffic bursts people like jon crowcroft keep complaining about.

Just to be on the safe side, though, we can use diff-serv as
a QoS mechanism to select packets which are discardable (mostly
random UDP things like DNS queries) and those that really can't
sustain loss due to data corruption, and are in need of extra
special handling by the link layer.

Right?

	Sean.

---

From: Dave Mills <[email-masked]>
Date: Thu, 24 Jun 1999 00:17:50 EDT

Folks,

The transient response of this discussion has a ringing component with
period maybe ten years. SATNET comes rollicking to mind, along with
packet radio and, would you believe, radio amateur packet radio. Tom
Clark W3IWI, a scientist probably not known to most of you, and I had
a FCC Special Temporary Authorization to come up ASCII on the radio
before it was eventually legalized. This back in the early eighties
and when TCP was very young. The protocol then and now used on HF and
VHF links was a ripoff of X.25, which used LAPB between packet
repeaters. I first used TCP over a concatenation of repeaters to read
my mail at 300 bps using a Terminal Node Controller and Phil Karn's
KISS interface. For the record, the end systems were fuzzballs running
much crafted TCP and a modified RTT algorithm that used asymmetric time
constants. A radio guy would say it looked like a diode peak detector.

I say this only to reveal my credentials as past experimentalist in the
link/end-end error control discussion. However, the links themselves
had highly variable error rates ranging from essentially error free to
an error for every two packets sent. Obviously, the ARQ strategy should
depend on the measured error rate and ambient delays and maybe other
factors. My problem was that the ARQ protocol was in ROM in the terminal
controllers and I was too lazy to pry the bits. However, I did take
the opportunity to experiment with routing lookaround schemes. For
record, my blunders are recorded in a CCR paper of January 1989 and
stashed at www.eecis.udel.edu/~mills/papers.htm.

The conclusion I drew in my youthful exuberances were two: First, the
link/end-end ARQ strategy has to operate on a shared database and
neither could work in isolation from the other. Second, these
schemes must be combined with some sort of FEC in a seamless transition
between error regimes from essentially the noise threshold to essentially
error free. The best example of this is a system my team designed
(I was team leader in a prior life for a CIA contract for their Mercury
network). While not classified, the system was considered proprietary.
It used ARQ, FEC and logical links (remember ARPANET). One of the
nice features built into the design was a good prediction of link
delay as it wandered all over the place due to mode selection and
was then provided to upper protocol layers. In the classic sense, I
can't say a lot more, because then I would have to shoot myself.
It would be really interesting to recreate this work in a sanitary
environment, which leaves me out.

Dave