[Info-vax] TCPIP performance for VMS

[JF Mezei]

Ok have done further tests (not complete yet).

I read RFC 1193 which describes MTU discovery. I had spent considerable
amount of time wondering why my Mac wasn't recording any ICMP packets
since I thought this is what was exchanged during TCP session
establishement to guess the MTU.

This is not the case.
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
##
The TCP Maximum Segment Size (MSS) defines the maximum amount of data
that a host is willing to accept in a single TCP/IP datagram. This
TCP/IP datagram may be fragmented at the IP layer. The MSS value is sent
as a TCP header option only in TCP SYN segments. Each side of a TCP
connection reports its MSS value to the other side. Contrary to popular
belief, the MSS value is not negotiated between hosts. The sending host
is required to limit the size of data in a single TCP segment to a value
less than or equal to the MSS reported by the receiving host.
##



Basically, a host simply sets the "do not fragment" bit on packets and
sends packets with  the MSS reported by the destination until it
receives an ICMP pacet from a router along the line saying that the
packet bounced because it was too big.

Newer routers will include in that ICMP packet the recommended MSS for
that hop, after which the sender can lower the MSS to the destination to
that value and send packets with that MSS and with the "do not fragment"
bit still on.

For older routers, they will have a "0" in that field for the ICMP
message, and the sender then uses an in-house logic to lower/guess the
correct MSS value (half it and then increase it until it bounces again
for instance).

--------------

Now, with DSL routers having NAT it gets interesing as I am finding out
(Wireshark is incredible for that).

VAX sends the TCP SYN with MSS of 1460 specified (MSS = MTU - 40)
Router rewites the packet with MSS of 1452 before sending to host. So
remote host knows that it shouldn't send packets bigger than 1492.

Remote host responds with the SYN ACK and a 1460 MSS.
Router rewrites packet with MSS of 1452 before delivering it to the VAX.
Therefore, the VAX knows not to send packets larger than 1452 to that
destination.

So there never really needs to be a MTU discovery process because during
the TCP establishement phase, the 2 hosts are given by the DSL router
the proper MSS to use.

However, if along the line, there was a router that accepted only up to
500 bytes, then MTU discovery would kick in after one host sent its
first packet that was greater than 500 bytes.

And it gets interesting since with current routing algorythms, A->B can
use one route but B-> can use a totally different route which may not
have the same MSS ! But MTU discovery works fine since each host will
adjust to whataver MSS is acceptable for the current path.


Also, there does not appear to be a "MTU Discocery" bit in the TCP or IP
packets. (Wireshark doesn't show one).

So now my next step is to figure out why speedguide.net thinks the Mac
has MTU Discovery set to on but VMS doesn't.


OK, in terms of timestamps.

There is an option to timestamp EVERY packet in a TCP connection. This
enables the both hosts to calcukate average time to get an ack for a
acket they sent before and thus detect and deal intelligently with
congestion.

Congestion windows are different from send/receive windows and are not
included in packet formats.



Now, none of this explains why the VMS host is slower at sending a
binary file than the mac. :-( :-(

(and yes, they are on the same lan, same IP subnet, connected to the
same router, same DSL service and when tests are done, both connect to
the same FTP host at the other end.