[Info-vax] TCPIP performance for VMS

[jbriggs444 at gmail.com]

On Apr 23, 8:09 am, jbriggs... at gmail.com wrote:
> On Apr 22, 7:28 pm, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
>
>
>
>
>
> > jbriggs... at gmail.com wrote:
> > > However there's the interesting possibility that the PPPoE
> > > encapsulation is reducing the available MTU
>
> > It isn't a possibility, it is a fact. The PPPoE kludge reduces MTU to
> > 1492 (PPPoE header takes 8 btes minimum, and if you use MLPPP (multipe
> > links bonded into one), the headers are larger.
>
> > > clear or  ignored.  A MAC using a MTU less than 1500 could be getting
> > > its packets through intact while the DSL modem is forced to fragment
> > > full sized 1500 byte frames being emitted by the VMS box.
>
> > It wouldn't be the DSL modem, it would bethe router (semantics...). The
> > modem always fragments the PPPoE kludge into ancient ATM packets (53
> > byte packet, 48 byte payload).
>
> > > If the
> > > speed testing site is detecting IP fragments, it could be falsely
> > > concluding that PMTUD is not supported by the client
>
> > Thewww.speedguide.net:8080looksat the TCP options. And it says that
> > VMS doesn't have MTU discovery enabled. But the Mac has it. Both go
> > though the same router/link.
>
> PMTUD isn't implemented in the TCP options.  The DF bit is in the IP
> header.
> (semantics :-).
>
> If you're still using Cisco router gear, there is a tweak you can try.
>
> In interface configuration mode
>
>         ip tcp adjust-mss 1436   ! (or other selected value)
>
> This causes the router to reach into the TCP SYN and SYN+ACK packets
> and adjust the MSS advertised by the client to the server and the
> server to the client.  The upshot is that the two ends wind up sending
> smaller packets.- Hide quoted text -
>
> - Show quoted text -

Reading an earlier message from this morning, it appears that JF's NAT
router is already doing the same manipulations that "ip tcp adjust-
mss" would call for.