[Standards] RTT, take 2

Dave Cridland dave at cridland.net
Fri Jun 24 09:01:37 UTC 2011


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:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list