On Wed Jun 22 16:52:53 2011, Kevin Smith wrote:
I've performed a quick review of the new proposal. I have a handful
of
comments on the spec; I don't currently intend these to be blocking,
for my part, when Council vote to Experimental. I consider this a
vast
improvement over the first proposed version of the document.
Just to add...
The nice trip down memory lane in Section 1 paints a rather rosy
picture, I think.
Since I was actually about, and using the net, in those days, I feel
a flashback coming on.
The biggest problem for a lot of these systems was the lag and
network load they generated. This is evidenced in the way that
Nagle's algorithm is the default in BSD derived socket stacks, for
instance.
Most of the talkers switched to using line buffering, Internet BBS
developed clients (and/or CLients, depending on whether you were DOC
or YAWC) which provided local editing facilities. C{lL}ient
connections often got in ahead of the queue (remember queueing? No,
of course not...) because of the vastly lower network load they
generated, and people used them because of the vastly improved user
experience of local echo - remote echo being not only more painful on
its own, but in no small part due to the network load, latencies of
30 seconds or more were quite common.
I'd like to see, somewhere in this document, a discussion about
network load, and a consideration that clients (and possibly servers)
MAY, or possibly SHOULD, disable RTT if network conditions
deteriorate.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade