netdev - Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110627091136.GA10085@canuck.infradead.org>
Date:	Mon, 27 Jun 2011 05:11:36 -0400
From:	Thomas Graf <tgraf@...radead.org>
To:	Vladislav Yasevich <vladislav.yasevich@...com>
Cc:	Sridhar Samudrala <sri@...ibm.com>, linux-sctp@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each
 CHUNK is too aggressive

On Fri, Jun 24, 2011 at 11:21:11AM -0400, Vladislav Yasevich wrote:
> We, instead of trying to underestimate the window size, try to over-estimate it.
> Almost every implementation has some kind of overhead and we don't know how
> that overhead will impact the window.  As such we try to temporarily account for this
> overhead.

I looked into this some more and it turns out that adding per-packet
overhead is difficult because when we mark chunks for retransmissions
we have to add its data size to the peer rwnd again but we have no
idea how many packets were used for the initial transmission. Therefore
if we add an overhead, we can only do so per chunk.

> If we treat the window as strictly available data, then we may end up sending a lot more traffic
> then the window can take thus causing us to enter 0 window probe and potential retransmission
> issues that will trigger congestion control.  
> We'd like to avoid that so we put some overhead into our computations.  It may not be ideal
> since we do this on a per-chunk basis.  It could probably be done on per-packet basis instead.
> This way, we'll essentially over-estimate but under-subscribe our current view of the peers
> window.  So in one shot, we are not going to over-fill it and will get an updated view next
> time the SACK arrives.

What kind of configuration showed this behaviour? Did you observe that
issue with Linux peers? If a peer announces an a_rwnd which it cannot
handle then that is a implementation bug of the receiver and not of the
sender.

We won't go into zero window probe mode that easily, remember it's only
one packet allowed in flight while rwnd is 0. We always take into
account outstanding bytes when updating rwnd with a_rwnd so our view of
the peer's rwnd is very accurate.

In fact the RFC clearly states when and how to update the peer rwnd:

   B) Any time a DATA chunk is transmitted (or retransmitted) to a peer,
      the endpoint subtracts the data size of the chunk from the rwnd of
      that peer.

I would like to try and reproduce the behaviour you have observed and
fix it without cutting our ability to produce pmtu maxed packets with
small data chunks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html