What encapsulation are they using to transmit CHAOS packets (over the Internet, I assume)? I know there was an IP protocol number assigned for CHAOS (16.), but I don't recall if there was ever a spec? (Which is kind of amusing, since in 'Assigned Numbers', the person responsible for 16. is .... me! :-) There was a spec for encapsulating IP in CHAOS, and that actually _was_ implemented at MIT BITD; it was used for a while to get IP traffic to a Unix machine (V7, IIRC) over on main campus, at a stage when only CHAOS hardware (very confusing that the same name was applied to hardware, and a protocol suite) ran across to main campus from Tech Square. Let's think through the details. The near-end 'invisibility box' (let's call it) is going to have to send acks to the original source machine, otherwise that will time out, abort the connection, etc. The originating machine is its own thing, and this behaviour can't be controlled/stopped. (This, BTW, shows a key difference between 'local' and 'across network' modes, a recent topic here; in a situation where two distinct machines are cooperating across a network, the other machine is its own entity, and can't be expected/guaranteed to do anything in particular at all.) In addition, the near-end invisibility box is going to have to keep a copy of each packet, until the destination machine sends an ack to the invisibility box - because if the packet is lost, the invisibility box is going to have to retransmit it. (The original source is not going to - it's already gotten an ack, so as far as it's concerned, that packet is done and dusted.) And the near-end invisibility box is also going to have to have to have a time-out timer, so that when the ack isn't seen, it will know to retransmit the packet. There's no point to _also_ sending the acks on to the originating machine; they won't do anything useful, and might just confuse it. So, let's see now: the near-end invisibility box buffers the packet, looks for an ack, times out when it doesn't see it, re-transmits the packet - that sounds familiar? Oh, right, it's a reliable connection. And presumably there's an invisibility box at the far end too, so the same can happen for any data packets the destination machine sends. The only question is whether, when doing the detailed design, there's any point to having the destination machine's acks sent to the near-end invisibility box - or just use them at the far-end invisibility box. (I.e. create three reliable connections: i) a CHAOS connection originating machine<->near-end invisibility box; ii) {whatever} near-end invisibility ox<->far-end invisibility box; iii) CHAOS far-end invisibility box<->original destination machine - and glue them together.) That is in some sense simpler than creating an extra-ordinary mechanism to have a 'helper' box in the middle of the connection (to terminate the CHAOS connection from the original machine, and have another CHAOS connection, but with an enhanced time-out mechanism which can cope with larger RTT's, from there to the original destination); and the same in the other direction. The amusing thing is that the CHAOS protocol stack actually already had something very similar to this, BITD. If one were sitting at a machine that only had CHAOS, and one wanted to (say) TELNET to an ARPANET host, there was a CHAOS service which ARPANET hosts on the CHAOSNET provided: open a CHAOS connection to that serrver, and it would open an NCP connection to one's intended ultimate destination, and glue the byte streams together. (The ultimate destination was passed as data over the CHAOS connection, when opening it.) Noel