Re: Changing TCP MSS under LINUX

On 22 Mai, 19:21, Rick Jones <rick.jon...@xxxxxx> wrote:
oleksandr kalinin <alexk...@xxxxxxxxxxxxxx> wrote:
Someone else points-out that this should not happen. What should
happen is one of two things:

a) The IP datagram carrying the TCP segment has the DF bit set in the
IP header. At the point where the packet becomes too large, that
router is required to return an ICMP Destination Unreachable, Datagram
Too Large message back to the source, which will then perform some
PathMTU discovery magic and reduce the Path MTU to that destination.
That will cause TCP to send smaller segments to avoid fragmentation.

b) The DF bit is not set in the header of the IP datagram carrying the
TCP segment - the device is supposed to fragment the IP datagram into
pieces which do fit and send them on their way.

If the fancy feature in the network cannot do either of these things
then it is fundamentally flawed and should be removed from the
network.


Agreed with that completely, and I have already indicated that to
people who control the faulty network. Unfortunately, making correct
statement does not necessarily mean that network fix will become true
soon, that is 'real world' of global private networks... Until network
is fixed, I would like to have some workaround in place.

For cases like this, I would like to have a possibility for
workaround, to decrease send MSS so that outgoing frames fit into
MTU bottleneck.
I know following MSS manipulation mechanisms under LINUX :
- Setting a static route with particular MSS. Alas, that only
changes TCP receive MSS, the one which is announced to remote peer
during TCP handshake. It does not affect send MSS.

I thought that static routes had Path MTUs associated with them. That
would in turn influence the MSS TCP advertises. It was my
understanding that the MSS used was the smaller of the two advertised
during connectoin establishment.

route utility contains -mss option, which may be used to force
changing TCP MSS on particular route.

In case I set static route with -mss 1300, LINUX will advertise
MSS=1260, but for outgoing MSS it will use the value advertised by
remote peer and that is what creates a problem. Indeed, RFC 879 ch. 3
says :

"The MSS can be used completely independently in each direction of
data flow. The result may be quite different maximum sizes in the two
directions."

RFC does not seem to recommend using smaller MSS out of two, so LINUX
behaves correctly in this case.

Thanks for your comments, anyway!

Regards,
Oleksandr

.

Relevant Pages

  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)