Optimizing Question

We have Client users who user the great Client ability to send and receive to POP3 and IMAP accounts that are "outside" of the GroupWise system (like gmail and yahoo). However, when large file attachments come in, the Client "freezes" during the duration the attachment is downloaded. ... None of these "outside" email imports flow through the GWIA and I wouldn't think they would. So this is probably a stupid question, but is there a way to make use of great Client ability to send and receive email from "outside" accounts and avoid the "freeze" that happens when large attachments come in? Clients are running direct access with Post Office (which works fine). ... Probably no solution, but just thought I would post.

Tags:

Parents
  • In article <holub457.8dvge0@no-mx.forums.microfocus.com>, Holub457
    wrote:
    > but is there a way to make use of great Client ability to send
    > and receive email from "outside" accounts and avoid the "freeze" that
    > happens when large attachments come in? Clients are running direct
    > access with Post Office (which works fine).


    Try running those instances of the client in caching mode to make sure
    that multi threading logic is running. I typically run in caching mode
    and haven't seen such issues, but then I don't recall much in the way
    of large attachments on those accounts.
    Does the system the Client runs on have multiple cores? How tight do
    the run on RAM? When such a message is coming it, is the hard drive
    activity light on most of the time?


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • We'll give caching mode a try. Typical system is running Intel i7 CPU with 32 GB RAM and SSD. Very fast machines and very fast internet connect. Slowness is likely at the gmail and yahoo server levels.
  • holub457 wrote:

    >
    > Just a further update. ... Set user external account access (gmail,
    > yahoo, etc) to IMAP. Large attachments download very rapidly under
    > IMAP. So POP3 slow attachment downloads (and Client freezing for
    > duration of download) are function of Client presumably, or ALL third
    > party POP3 servers are slow (which is highly unlikely).


    One cannot determine an appropriate solution until the actual caused is
    determined. You have suggested a couple of possible causes. The next
    step is to validate your assumptions.

    If you Google "pop3 download slow" there are lots of hits, many going
    back ten years and many involving Outlook so I would suspect this is
    not specifically a GroupWise issue.

    You say that IMAP doesn't experience the same issue. Perhaps you could
    run a packet trace with Wireshark while retrieving the same email via
    POP3 and IMAP4. Comparing the two packet traces may provide some
    insight.

    You may also test using different POP3 clients, perhaps trying one
    running on Linux. The results of these tests may show similar results
    to those you describe using GroupWise. If so, that would suggest the
    issue is unrelated to the GroupWise client.


    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • Well, Wireshark trace shows simply that the packets transmitted with POP3 are small packets. 54 bytes. No actual errors show. Just small packets. However, packet size for IMAP is also small 54 bytes. Nothing whatsoever shows basis of slow transmission. However, and this might be big, every 25 packets the POP3 times out with a Zero Window. Apparently, this means "... client is not able to receive further information at the moment, and the TCP transmission is halted until it can process the information in its receive buffer." ... This seems to fit with the old posts about Outlook. ... But, no idea how to fix.
  • holub457 wrote:

    > This seems to fit with the old
    > posts about Outlook. ... But, no idea how to fix.


    Does this KB article apply or help?
    https://support.microsoft.com/en-us/help/935400/it-takes-much-longer-than-expected-to-download-an-e-mail-message-from

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • Well either with settings of
    netsh interface tcp set global autotuninglevel=disabled
    or
    netsh interface tcp set global autotuninglevel=normal

    the result is the same in the Wireshark logs.
  • holub457 wrote:

    >
    > Well either with settings of
    > netsh interface tcp set global autotuninglevel=disabled
    > or
    > netsh interface tcp set global autotuninglevel=normal
    >
    > the result is the same in the Wireshark logs.


    That's unfortunate but at least it eliminates one possible cause.

    If the packet traces of the IMAP4 and POP3 downloads are essentially
    the same other than...
    > every 25 packets the POP3 times out with a Zero Window.

    I would try to determine why this is happening.

    See if you observe the same behaviour using a different POP3 client
    and/or running from a different platform (Mac or Linux).

    The goal is to try to identify what conditions might cause these slow
    downloads or to eliminate the timeout as the issue.

    At the moment I don't have any additional ideas.

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • FYI I think it is definitely related to buffer getting filled up. Wireshark says transmitt from POP3 is filling up local machine.

    [TCP Window Full] 995 -> 55675 [ACK] Seq=6467970 Ack=698 Win=16616 Len=1460 [TCP segment of a reassembled PDU]

    Windows may be problem, or POP3 server may be part of problem. I'll try a different POP3 client as an experiment.
  • holub457 wrote:

    > FYI I think it is definitely related to buffer getting filled up.
    > Wireshark says transmitt from POP3 is filling up local machine.
    >
    > [TCP Window Full] 995 -> 55675 [ACK] Seq=6467970 Ack=698 Win=16616
    > Len=1460 [TCP segment of a reassembled PDU]


    See this:
    https://osqa-ask.wireshark.org/questions/24501/why-would-tcp-full-window-happen

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • Kevin Boyle wrote:

    > holub457 wrote:
    >
    > > FYI I think it is definitely related to buffer getting filled up.
    > > Wireshark says transmitt from POP3 is filling up local machine.
    > >
    > > [TCP Window Full] 995 -> 55675 [ACK] Seq=6467970 Ack=698 Win=16616
    > > Len=1460 [TCP segment of a reassembled PDU]

    >
    > See this:
    >

    https://osqa-ask.wireshark.org/questions/24501/why-would-tcp-full-window-happen

    I've looked into this a bit further.

    If you see [TCP Window Full], it usually means the sender is sending
    data faster than the application is retrieving the data from the
    buffer. That might suggest an issue with the client.

    This article discusses how to assess the impact of [TCP Window Full]
    Network Analysis: TCP Window Size
    https://www.networkcomputing.com/careers/network-analysis-tcp-window-size/97729416

    If this is your issue, resolving it is another matter but at least it
    points you in the right direction.

    Í don't know if this applies in your situation but you may want to
    consider it...

    This Wikipedia article points out:
    "Because some firewalls do not properly implement TCP Window Scaling,
    it can cause a user's Internet connection to malfunction intermittently
    for a few minutes, then appear to start working again for no reason.
    There is also an issue if a firewall doesn't support the TCP extensions.
    https://en.wikipedia.org/wiki/TCP_window_scale_option


    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • So, accessing with Outlook to same POP3 account downloads in few seconds the same file that takes 5 min under Groupwise. Wireshark shows no errors or bottlenecks with Outlook. Here is what download attempt shows with Groupwise. I think I will need to open a ticket.

    870 17.774239 xx.xx.xx.xx yy.yy.yy.yy TCP 1514 995 → 55675 [ACK] Seq=408970 Ack=698 Win=16616 Len=1460 [TCP segment of a reassembled PDU]
    871 17.774258 yy.yy.yy.yy xx.xx.xx.xx TCP 54 55675 → 995 [ACK] Seq=698 Ack=410430 Win=2920 Len=0
    872 17.833778 xx.xx.xx.xx yy.yy.yy.yy TCP 1514 995 → 55675 [ACK] Seq=410430 Ack=698 Win=16616 Len=1460[Reassembly error, protocol TCP: New fragment past old data limits]
    873 17.834112 xx.xx.xx.xx yy.yy.yy.yy TCP 1514 [TCP Window Full] 995 → 55675 [ACK] Seq=411890 Ack=698 Win=16616 Len=1460 [TCP segment of a reassembled PDU]
    874 17.834144 yy.yy.yy.yy xx.xx.xx.xx TCP 54 [TCP ZeroWindow] 55675 → 995 [ACK] Seq=698 Ack=413350 Win=0 Len=0
    875 17.937890 yy.yy.yy.yy xx.xx.xx.xx TCP 54 [TCP Window Update] 55675 → 995 [ACK] Seq=698 Ack=413350 Win=64240 Len=0
    876 17.998928 xx.xx.xx.xx yy.yy.yy.yy TCP 1514 995 → 55675 [ACK] Seq=413350 Ack=698 Win=16616 Len=1460 [TCP segment of a reassembled PDU]
    877 17.998930 xx.xx.xx.xx yy.yy.yy.yy TCP 1514 995 → 55675 [ACK] Seq=414810 Ack=698 Win=16616 Len=1460[Reassembly error, protocol TCP: New fragment past old data limits]
    878 17.999014 yy.yy.yy.yy xx.xx.xx.xx TCP 54 55675 → 995 [ACK] Seq=698 Ack=416270 Win=64240 Len=0
    879 17.999242 xx.xx.xx.xx yy.yy.yy.yy TCP 1514 995 → 55675 [ACK] Seq=416270 Ack=698 Win=16616 Len=1460 [TCP segment of a reassembled PDU]
  • On 12.03.2018 20:04, holub457 wrote:
    > [Reassembly error, protocol TCP:
    > New fragment past old data limits]


    Did you see this? Something is malfunctioning here.

    Also, your clients sends a window of 2920 bytes still available in
    packet 871 (Window=2920), then it receives a 1460 byte segment and
    responds with window full. That shouldn't be possible, and is another
    pointer to some underlying communication failing badly.

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
Reply
  • On 12.03.2018 20:04, holub457 wrote:
    > [Reassembly error, protocol TCP:
    > New fragment past old data limits]


    Did you see this? Something is malfunctioning here.

    Also, your clients sends a window of 2920 bytes still available in
    packet 871 (Window=2920), then it receives a 1460 byte segment and
    responds with window full. That shouldn't be possible, and is another
    pointer to some underlying communication failing badly.

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
Children
No Data