Re: Poor mil/arpa performance

Mike Brescia (brescia@BBNCCV.ARPA)
28 Feb 86 09:03:23 EST (Fri)

     response is SO BAD that we are actively trying to have her and her
     associates moved from arpa2-mil-tac to arpa3-tac in hopes of her
     getting characters echoed is less than geological time.

The idea of homing choice between mil- and arpa-net was to put users and hosts
on the correct net, or the most used net for that host or person.

What kind of terminal is she using, and is she telnet-ing to seismo
( or going to one of your hosts on local nets? The terminal type
would mainly govern what kind of applications she uses; video at 9600 baud
would imply using a screen editor, and I find with emacs/pen that
psychologically, I expect (DEMAND!) quick response.

The TAC software version, and transmit mode effect how much the characters are
accumulated above one keystroke per packet. (Is she a 5wpm typist, or 50 wpm?)
What about your host and its approach to echo characters? Are you forcing the
exchage of 8 packets for every keystroke? ((key + echo) * tcp-ack * rfnm)

     It's kind of scary thinking about how far the packets are really going
     to traverse that 100 yards seperating us physically.

It's the smallest possible, since the connection is
        tac - milimp106 - gateway - arpaimp28 - arpaimp25 - seismo
(However if the connection is to a local net at seismo, all bets are off. The
route is guaranteed to be ++~good.)

     The arpa/milnet bridges are clearly inadequate.

The fact that they are allowed to drop packets (because they have no handle to
do flow control) means the end point TCP must make up for it. Lacking a
commitment to deliver is a strange way to run a railroad. Let's fix it.


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:04 GMT