Path MTU discovery

[Francesco Gennai]

Process Software MultiNet V5.1 Rev A-X, COMPAQ AlphaServer DS20E 833 MHz,
OpenVMS AXP V8.2

Do you know if are there problem with the command
(to disable the Path MTU Discovery function):

$ multinet set/kernel tcp_pmtu 0

with MultiNet V5.1 ?

I think.... (not verified), that it ceased to work with version 5.1.
Infact, after the upgrade from 5.0 to 5.1 connectivity problems
due to MTU are come back again. Such problem was eliminated by
disabling the Path MTU Discovery.

Regards,
Francesco Gennai

[Jens S Andersen]

Disabling PMTU is not a good idea. You will get into more troubble with sites
accessible via f.ex. GRE tunnels.

However I got in troubble when I upgraded from v 4.4 to 5.1. I had to revert
to 4.4 due to MTU problems.

Is there a way to wiev the kernel paramerers?

-Jens

Post by Francesco Gennai
Process Software MultiNet V5.1 Rev A-X, COMPAQ AlphaServer DS20E 833 MHz,
OpenVMS AXP V8.2
Do you know if are there problem with the command
$ multinet set/kernel tcp_pmtu 0
with MultiNet V5.1 ?
I think.... (not verified), that it ceased to work with version 5.1.
Infact, after the upgrade from 5.0 to 5.1 connectivity problems
due to MTU are come back again. Such problem was eliminated by
disabling the Path MTU Discovery.
Regards,
Francesco Gennai

Jens S Andersen Email: ***@adm.aau.dk
Aalborg University Telf: 9635 9464
Fredrik Bajers Vej 5 Fax: [phone]
9220 Aalborg
Denmark

[Jim Mehlhop]

Post by Jens S Andersen
Disabling PMTU is not a good idea. You will get into more troubble with sites
accessible via f.ex. GRE tunnels.
However I got in troubble when I upgraded from v 4.4 to 5.1. I had to revert
to 4.4 due to MTU problems.
Is there a way to wiev the kernel paramerers?

Yes

SYS6$ multinet set/kernel tcp_pmtu
Parameter tcp_pmtu (0x846D3E50), Value = 1
SYS6$

However that doesn't tell us if it does anything or not, just that it
exists and we can look/set it

Post by Jens S Andersen
-Jens

Post by Francesco Gennai
Process Software MultiNet V5.1 Rev A-X, COMPAQ AlphaServer DS20E 833 MHz,
OpenVMS AXP V8.2
Do you know if are there problem with the command
$ multinet set/kernel tcp_pmtu 0
with MultiNet V5.1 ?
I think.... (not verified), that it ceased to work with version 5.1.
Infact, after the upgrade from 5.0 to 5.1 connectivity problems
due to MTU are come back again. Such problem was eliminated by
disabling the Path MTU Discovery.
Regards,
Francesco Gennai

Aalborg University Telf: 9635 9464
Fredrik Bajers Vej 5 Fax: [phone]
9220 Aalborg
Denmark

Jim Mehlhop

Join Cauce to outlaw spam
http://www.cauce.org/

[Richard Whalen]

Before KERNEL-UPDATE-092_A051 the TCP code did not subtract the length of the options from the amount of data that could be put in a MSS packet. Though my reading of RFC 879 is that it should not be subtracted, it appears to be common practice to subtract it. Not subtracting the length of the options would cause larger than MSS packets to be sent, which would cause some routers to drop the packets.

The tcp_pmtu variable should be able to disable path MTU discovery.

-----Original Message-----
From: Jens S Andersen [mailto:***@aua.auc.dk]
Sent: Tuesday, August 29, 2006 4:52 AM
To: Francesco Gennai
Cc: info-***@process.com
Subject: Re: Path MTU discovery


Disabling PMTU is not a good idea. You will get into more troubble with sites
accessible via f.ex. GRE tunnels.

However I got in troubble when I upgraded from v 4.4 to 5.1. I had to revert
to 4.4 due to MTU problems.

Is there a way to wiev the kernel paramerers?

-Jens

Post by Francesco Gennai
Process Software MultiNet V5.1 Rev A-X, COMPAQ AlphaServer DS20E 833 MHz,
OpenVMS AXP V8.2
Do you know if are there problem with the command
$ multinet set/kernel tcp_pmtu 0
with MultiNet V5.1 ?
I think.... (not verified), that it ceased to work with version 5.1.
Infact, after the upgrade from 5.0 to 5.1 connectivity problems
due to MTU are come back again. Such problem was eliminated by
disabling the Path MTU Discovery.
Regards,
Francesco Gennai

Jens S Andersen Email: ***@adm.aau.dk
Aalborg University Telf: 9635 9464
Fredrik Bajers Vej 5 Fax: [phone]
9220 Aalborg
Denmark

[Mike Sullenberger]

Post by Richard Whalen
Before KERNEL-UPDATE-092_A051 the TCP code did not subtract the length
of the options from the amount of data that could be put in a MSS packet.
Though my reading of RFC 879 is that it should not be subtracted, it
appears to be common practice to subtract it. Not subtracting the
length of the options would cause larger than MSS packets to be sent,
which would cause some routers to drop the packets.
The tcp_pmtu variable should be able to disable path MTU discovery.

For TCP MSS calculations the IP and TCP headers are assumed to be 20
bytes each. If this is not the case then it is the hosts responsibility
to subtract the length of the additional IP or TCP options from the
length of the TCP payload to ensure that the total IP packet size is
not greater than TCP MSS + 40 for that session.

From RFC1122

4.2.2.6 Maximum Segment Size Option: RFC-793 Section 3.1

TCP MUST implement both sending and receiving the Maximum
Segment Size option [TCP:4].

TCP SHOULD send an MSS (Maximum Segment Size) option in
every SYN segment when its receive MSS differs from the
default 536, and MAY send it always.

If an MSS option is not received at connection setup, TCP
MUST assume a default send MSS of 536 (576-40) [TCP:4].

The maximum size of a segment that TCP really sends, the
"effective send MSS," MUST be the smaller of the send MSS
(which reflects the available reassembly buffer size at the
remote host) and the largest size permitted by the IP layer:

Eff.snd.MSS =

min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize

where:

* SendMSS is the MSS value received from the remote host,
or the default 536 if no MSS option is received.

* MMS_S is the maximum size for a transport-layer message
that TCP may send.

* TCPhdrsize is the size of the TCP header; this is
normally 20, but may be larger if TCP options are to be
sent.

* IPoptionsize is the size of any IP options that TCP
will pass to the IP layer with the current message.



Mike.

+-----------------------------------------------------------------------+
| || || |
| Mike Sullenberger || || |
| ***@cisco.com |||| |||| |
| Escalation Team |||||||| |||||||| |
| Customer Advocacy ..:|||||||||||||||||||||:.. |
| C i s c o S y s t e m s |
+-----------------------------------------------------------------------+

[Francesco Gennai]

Well... I installed the patch:
KERNEL-UPDATE-101_A051
and the problem disappeared.

To summarize:
the nodes with Multinet (are 2 nodes in cluster) runs an e-mail server
that of course open SMTP connections with hundreds of destinations.
With few of them there was a problem on the SMTP sessions that didn't
complete successfully, expecially for long messages.

My question is:
was Multinet (before this update) compliant with the standard ?

From the Multinet KERNEL-UPDATE-101_A051.README

- Subtract the length of the options to be sent as part of TCP packets
when sending a packet with MSS data as there are some systems and
routers that misinterpret the MSS option in RFC 879 as the maximum
beyond the minimum length headers.
(DE 10265 ECO KERNEL-UPDATE-092_A051) ECO Rank: 3

Thanks to everyone for yours answers to my previous posting.

Francesco

Post by Richard Whalen
Before KERNEL-UPDATE-092_A051 the TCP code did not subtract the length
of the options from the amount of data that could be put in a MSS packet.
Though my reading of RFC 879 is that it should not be subtracted, it
appears to be common practice to subtract it. Not subtracting the
length of the options would cause larger than MSS packets to be sent,
which would cause some routers to drop the packets.
The tcp_pmtu variable should be able to disable path MTU discovery.

For TCP MSS calculations the IP and TCP headers are assumed to be 20
bytes each. If this is not the case then it is the hosts responsibility
to subtract the length of the additional IP or TCP options from the
length of the TCP payload to ensure that the total IP packet size is
not greater than TCP MSS + 40 for that session.
From RFC1122
4.2.2.6 Maximum Segment Size Option: RFC-793 Section 3.1
TCP MUST implement both sending and receiving the Maximum
Segment Size option [TCP:4].
TCP SHOULD send an MSS (Maximum Segment Size) option in
every SYN segment when its receive MSS differs from the
default 536, and MAY send it always.
If an MSS option is not received at connection setup, TCP
MUST assume a default send MSS of 536 (576-40) [TCP:4].
The maximum size of a segment that TCP really sends, the
"effective send MSS," MUST be the smaller of the send MSS
(which reflects the available reassembly buffer size at the
Eff.snd.MSS =
min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
* SendMSS is the MSS value received from the remote host,
or the default 536 if no MSS option is received.
* MMS_S is the maximum size for a transport-layer message
that TCP may send.
* TCPhdrsize is the size of the TCP header; this is
normally 20, but may be larger if TCP options are to be
sent.
* IPoptionsize is the size of any IP options that TCP
will pass to the IP layer with the current message.
Mike.
+-----------------------------------------------------------------------+
| || || |
| Mike Sullenberger || || |
| Escalation Team |||||||| |||||||| |
| Customer Advocacy ..:|||||||||||||||||||||:.. |
| C i s c o S y s t e m s |
+-----------------------------------------------------------------------+