Deleting an RSPF interface

[Gareth Howell <garethh@compulink.co.uk>]

Is there any way of switching rspf off on an interface you have
previously defined it on?
Gareth
----------------------------------------------------------------
Gareth Howell G6KVK
g6kvk@g6kvk.ampr.org          AMPRNET          [44.131.19.1]
garethh@compulink.co.uk       EUNET
g6kvk@gb7khw._2111.gbr.eu     UK BBS Network
29 Blackmore, Letchworth, Herts ENGLAND SG6 2SX +44 (462) 677090
----------------------------------------------------------------

OS, but a couple are running MSYS; one of
whom is our local BBS gateway. Most of the time the error rates are
fairly low, so I think we could get away with long segments, but
sometimes we get significant interference.

One of the tests we did was as follows, KISS TNCs, 2400 local
connections to TNC, 1200 Media speed, 512 MTU, 1024 MSS, 2048
Window. Transferring a 5k file we got about 55 char/s. To assess the
effect of using VC mode (with a 512 PACLEN) we did the same transfer
and achieved about 19 char/s. On looking at the trace log I noticed
the following:

1. Virtually no piggy-backing of Layer 2 RRs on I frames, thus a lot
of RR frames were flying around.

2. Link layer segmentation worked OK except that the first TCP
segment of the transfer was different from the rest. TCP signalled a
segment of 469 data, which was split by ax25 into _2_ link segments,
one full and the other with 40 data.
All other TCP segments of this length were split into
_3_ link segments; 2 full and the third part full, (i.e. they were
256 bytes too long). However the destination TCP didn't report a
checksum error on any segment!! (How come?) (I can provide the trace
log if requested).

3. Considerable link congestion occurred. The link srtt levelled out
at about 2.9 secs but after a few tcp segments were sent a backlog of
about 14 ax25 frames existed. This caused the collapse of the link as
follows:

  TCP sent 469 data, split into (3) ax25 frames.

  TCP sent a second segment of 469, split into (3) ax25 frames.
  Ax25 was still sending the previous frame but the tcp window
  enabled tcp to send this new segment.

  Ax25 eventually sent the first segment.

  The remote end sent a TCP ACK for the first segment which went
  straight through as the reverse queue was empty.

  The local TCP saw the ACK for the first segment and re-sent the
  second segment, which was still being transmitted, thus causing a
  100% resend overhead for no reason.

How can we avoid this if we are to use VC mode.

In my view, we could have avoided the first problem (no
piggy-backing) by making the T2 timer longer, (we could have set
MAXFRAME > 1 but we all know the problem with that).

What was the cause of (2) though, and how do we avoid (3)?

73 Gareth
----------------------------------------------------------------
Gareth Howell G6KVK
g6kvk@g6kvk.ampr.org          AMPRNET          [44.131.19.1]
garethh@compulink.co.uk       EUNET
g6kvk@gb7khw._2111.gbr.eu     UK BBS Network
29 Blackmore, Letchworth, Herts ENGLAND SG6 2SX +44 (462) 677090
----------------------------------------------------------------