Is increasing TCP MSS Ok? - TCP-IP

This is a discussion on Is increasing TCP MSS Ok? - TCP-IP ; The delay/latency for sending a TCP packet from server to the client is fine in our setup. But, it becomes worse, when the actual LDAP responses are sent. The response can be about 5K. As the TCP MSS ia about ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Is increasing TCP MSS Ok?

  1. Is increasing TCP MSS Ok?

    The delay/latency for sending a TCP packet from server to the client
    is fine in our setup.
    But, it becomes worse, when the actual LDAP responses are sent. The
    response can be about 5K. As the TCP MSS ia about 1K, the response is
    sent in 5 segments. This is seen a higher latency by our applications.

    The main problem is that our application processes are not able to
    handle such higher latencies. So, as a quicker work-around, we would
    like to increase the TCP MSS. In my understanding, the change should
    be done both at the client and server. Is that correct?

    Also, I would like to know whether there are any side effects/things
    to be taken care due to this.


  2. Re: Is increasing TCP MSS Ok?

    In article <1180507619.948054.173360@o11g2000prd.googlegroups. com>,
    "qazmlp1209@rediffmail.com" wrote:

    > The delay/latency for sending a TCP packet from server to the client
    > is fine in our setup.
    > But, it becomes worse, when the actual LDAP responses are sent. The
    > response can be about 5K. As the TCP MSS ia about 1K, the response is
    > sent in 5 segments. This is seen a higher latency by our applications.
    >
    > The main problem is that our application processes are not able to
    > handle such higher latencies. So, as a quicker work-around, we would
    > like to increase the TCP MSS. In my understanding, the change should
    > be done both at the client and server. Is that correct?
    >
    > Also, I would like to know whether there are any side effects/things
    > to be taken care due to this.


    If you make the MSS larger than the path MTU you'll get fragmentation,
    which can cause performance problems. Most implementations use Path MTU
    Discovery to set the MSS to just under the path MTU, so segments will be
    as big as possible without causing fragmentation. So the same number of
    packets will be sent as when you increase the MSS.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: Is increasing TCP MSS Ok?

    In comp.protocols.tcp-ip qazmlp1209@rediffmail.com wrote:
    > The delay/latency for sending a TCP packet from server to the client
    > is fine in our setup.


    > But, it becomes worse, when the actual LDAP responses are sent. The
    > response can be about 5K. As the TCP MSS ia about 1K, the response
    > is sent in 5 segments. This is seen a higher latency by our
    > applications.


    How/why? What is the latency, what is the bitrate of the path between
    the two endpoints?

    > The main problem is that our application processes are not able to
    > handle such higher latencies. So, as a quicker work-around, we would
    > like to increase the TCP MSS. In my understanding, the change should
    > be done both at the client and server. Is that correct?


    Depending on what the actual root cause of the latency issue happens
    to be, all increasing the MSS, as someone else points-out, will do is
    cause your TCP traffic to be IP fragmented. If any one IP datagram
    fragment of the IP datagram carrying the TCP segment is lost, the
    _entire_ TCP segment must be retransmitted. This has the effect of a
    multiplicative (or is it exponential?) increase of the low-level
    packet loss rate to a rather higher TCP segment loss rate.

    rick jones
    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  4. Re: Is increasing TCP MSS Ok?

    On Wed, 30 May 2007 05:24:50 -0400, Barry Margolin wrote:

    > In article <1180507619.948054.173360@o11g2000prd.googlegroups. com>,
    > "qazmlp1209@rediffmail.com" wrote:
    >
    >> The delay/latency for sending a TCP packet from server to the client is
    >> fine in our setup.
    >> But, it becomes worse, when the actual LDAP responses are sent. The
    >> response can be about 5K. As the TCP MSS ia about 1K, the response is
    >> sent in 5 segments. This is seen a higher latency by our applications.
    >>
    >> The main problem is that our application processes are not able to
    >> handle such higher latencies. So, as a quicker work-around, we would
    >> like to increase the TCP MSS. In my understanding, the change should be
    >> done both at the client and server. Is that correct?
    >>
    >> Also, I would like to know whether there are any side effects/things to
    >> be taken care due to this.

    >
    > If you make the MSS larger than the path MTU you'll get fragmentation,
    > which can cause performance problems. Most implementations use Path MTU
    > Discovery to set the MSS to just under the path MTU, so segments will be
    > as big as possible without causing fragmentation. So the same number of
    > packets will be sent as when you increase the MSS.


    Exactly. So THE way to increase your MSS is to increase your path MTU.
    Most links can handle 1500 byte packets, so your MSS should be 1460. If
    it is lower, investigate where the link is with the lower MTU and what
    can be done about that.

    But, think about this.

    Raising the MTU to 1460 may save one packet on the 5K your sending. Which
    means a saving of 40 bytes on every 5K, or about 0.8%. So I would not
    expect the performance to greatly increase.

    You say people are experiencing latency. You'd better investigate where
    this latency comes from. I doubt this really comes from the fact that
    multiple packets are sent. The server should send all 5 packets right
    after one another without waiting for an acknowledgment.

    If that is not the case, if the server really pauses between packets, you
    can expect some savings (in time) better than 0.8% by raising the MSS.
    However, in that case something else is very, very wrong and you should
    investigate why the server waits between packets and solve that for even
    more dramatic improvements.

    Time to fire up wireshark (formerly ethereal) and look what really goes
    on on the wire.

    HTH,
    M4

  5. Re: Is increasing TCP MSS Ok?

    In article ,
    Martijn Lievaart wrote:

    > On Wed, 30 May 2007 05:24:50 -0400, Barry Margolin wrote:
    >
    > > In article <1180507619.948054.173360@o11g2000prd.googlegroups. com>,
    > > "qazmlp1209@rediffmail.com" wrote:
    > >
    > >> The delay/latency for sending a TCP packet from server to the client is
    > >> fine in our setup.
    > >> But, it becomes worse, when the actual LDAP responses are sent. The
    > >> response can be about 5K. As the TCP MSS ia about 1K, the response is
    > >> sent in 5 segments. This is seen a higher latency by our applications.
    > >>
    > >> The main problem is that our application processes are not able to
    > >> handle such higher latencies. So, as a quicker work-around, we would
    > >> like to increase the TCP MSS. In my understanding, the change should be
    > >> done both at the client and server. Is that correct?
    > >>
    > >> Also, I would like to know whether there are any side effects/things to
    > >> be taken care due to this.

    > >
    > > If you make the MSS larger than the path MTU you'll get fragmentation,
    > > which can cause performance problems. Most implementations use Path MTU
    > > Discovery to set the MSS to just under the path MTU, so segments will be
    > > as big as possible without causing fragmentation. So the same number of
    > > packets will be sent as when you increase the MSS.

    >
    > Exactly. So THE way to increase your MSS is to increase your path MTU.
    > Most links can handle 1500 byte packets, so your MSS should be 1460. If
    > it is lower, investigate where the link is with the lower MTU and what
    > can be done about that.


    I suspect that 1460 is the "about 1k" that he referred to. So he's
    probably already there. Although if he's using a VPN and/or PPPoE-based
    DSL connection, the encapsulation overhead may be reducing his path MTU
    by about 100.

    > But, think about this.
    >
    > Raising the MTU to 1460 may save one packet on the 5K your sending. Which
    > means a saving of 40 bytes on every 5K, or about 0.8%. So I would not
    > expect the performance to greatly increase.
    >
    > You say people are experiencing latency. You'd better investigate where
    > this latency comes from. I doubt this really comes from the fact that
    > multiple packets are sent. The server should send all 5 packets right
    > after one another without waiting for an acknowledgment.


    Even with slow start?

    Another question: does the application open a new connection for each
    transaction? If so, the killer effect of high latency will be on the
    3-way SYN handshake, and increasing the MSS won't help with this.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  6. Re: Is increasing TCP MSS Ok?

    In comp.protocols.tcp-ip Barry Margolin wrote:
    > Even with slow start?


    Good question. With a ~1460 byte MSS one can have three segments in
    flight at one time (4380 bytes) for the initial cwnd, and one can
    reasonably ass-u-me an immediate ACK from the receive at that point of
    the connection even if it is a stack with an ACK avoidance heuristic.

    Then the next two segments should be able to fly, so it would be 1.5
    RTT from the time of connection establishment to get the 5 segments
    there. Two RTT for the answer (modulo its size and the service time).

    Definitely time for a packet trace.

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread