From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: linux-sctp@vger.kernel.org
Subject: Re: Broken sack processing
Date: Wed, 07 Nov 2018 12:53:14 +0000 [thread overview]
Message-ID: <20181107125314.GI6761@localhost.localdomain> (raw)
In-Reply-To: <5dcd9eb4ccf44ce293a73fb9ec4457cf@AcuMS.aculab.com>
On Wed, Nov 07, 2018 at 10:01:48AM +0000, David Laight wrote:
> I've a customer trace from a very old system (RHEL 5.7) that shows the
Ouch. That's really old. (and unsupported)
> kernel failing to respond to some SACK packets like:
>
> SACK chunk (Cumulative TSN: 3327915808, a_rwnd: 224400, gaps: 12, duplicate TSNs: 0)
> Chunk type: SACK (3)
> Chunk flags: 0x00
> Chunk length: 64
> Cumulative TSN ACK: 3327915808
> Advertised receiver window credit (a_rwnd): 224400
> Number of gap acknowledgement blocks: 12
> Number of duplicated TSNs: 0
> Gap Acknowledgement for TSN 3327915813 to 3327915814
> Gap Acknowledgement for TSN 3327915818 to 3327915818
> Gap Acknowledgement for TSN 3327915822 to 3327915838
> Gap Acknowledgement for TSN 3327915842 to 3327915852
> Gap Acknowledgement for TSN 3327915856 to 3327915858
> Gap Acknowledgement for TSN 3327915860 to 3327915864
> Gap Acknowledgement for TSN 3327915866 to 3327915866
> Gap Acknowledgement for TSN 3327915868 to 3327915869
> Gap Acknowledgement for TSN 3327915873 to 3327915877
> Gap Acknowledgement for TSN 3327915881 to 3327915892
> Gap Acknowledgement for TSN 3327915894 to 3327916102
> Gap Acknowledgement for TSN 3327916104 to 3327916172
> [Number of TSNs in gap acknowledgement blocks: 337]
>
> Does this ring a bell, any idea how long ago it was fixed?
I don't follow. What is broken in this SACK? And what does it mean
"kenrel fails to repond some SACK", like, is it not retransmitting?
> Not sure why the connection isn't dropped because of the unacked packets?
Whenever a new delivery is confirmed, the error count is zeroed. But,
once it enters RTO, it won't do new deliveries.
After a SACK like this I would expect some fast rtx, then RTO and then
a possible abort.
But if TSN 3327915809 (next after cumack) gets delivered, it will zero
the error count (again).
Is this connection triggering zero windows, by any chance? Doesn't
seem so, as per
Advertised receiver window credit (a_rwnd): 224400
Marcelo
next prev parent reply other threads:[~2018-11-07 12:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-07 10:01 Broken sack processing David Laight
2018-11-07 12:53 ` Marcelo Ricardo Leitner [this message]
2018-11-07 14:37 ` David Laight
2018-11-08 0:34 ` 'Marcelo Ricardo Leitner'
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181107125314.GI6761@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=linux-sctp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).