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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 09 May 2014 12:00:43 -0400 From: Jon Maloy <maloy@...jonn.com> To: David Laight <David.Laight@...LAB.COM>, "'erik.hugne@...csson.com'" <erik.hugne@...csson.com> CC: 'Jon Maloy' <jon.maloy@...csson.com>, "davem@...emloft.net" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Paul Gortmaker <paul.gortmaker@...driver.com>, "ying.xue@...driver.com" <ying.xue@...driver.com>, "tipc-discussion@...ts.sourceforge.net" <tipc-discussion@...ts.sourceforge.net> Subject: Re: [PATCH net-next 1/8] tipc: decrease connection flow control window On 05/09/2014 10:59 AM, David Laight wrote: > From: erik.hugne@...csson. >> On Fri, May 09, 2014 at 01:30:43PM +0000, David Laight wrote: >>> Sounds a bit like a badly designed protocol to me... >> Well, i don't like this either but the current message-oriented flowcontrol >> will eventually be replaced with a byte-based one. Right now we're trying >> to find a way to adapt a message-oriented flow control to per-socket buffer >> constraints, without breaking protocol compatibility. > I wasn't thinking of the byte/message flow control problems. > More of only requesting acks every 512 messages Acks are not requested, they are sent out unsolicited at fix intervals, controlled by the reading capacity of the receiving process. The fundamental problem we have is that we acknowledge messages, without considering their size, so a sender won't stop (there is no active stop message from the receiver) until he has sent 512 messages and not received an ack, which in the worst case amounts to 512 x truesize(64KB) = 67 MB outstanding data. This is what the receiving socket must be able to absorb, in order to avoid broken connections. If we acknowledge bytes instead of messages and possibly introduce a flexible acknowledge interval, this whole problem will go away, but until then (a few months from now, I think) we have do make the best out of what we have. > (if my quick reading of the proposed change is right). > Especially without the receiver being able to stop the sender when > there is a buffer crisis (of any kind) at the receiver. To use any form of active feedback to the sender sounds scary to me. Passive feedback, in the form of withheld acks, is the way to go. That is the way it works now, and the way it should work, it is just that the buffer limits we need to sustain this currently are insanely high. > > I guess the aim was to limit the 'back traffic' by making the > assumption that the receiving system would always be able to > process the data as fast as it arrived. > If the receiver is an embedded system this is unlikely to be true. True. Legacy TIPC comes from a world where memory constraints wasn't considered a big issue. That is different now, of course, and has to be remedied. > > I suspect you want the receiver to offer a large window (bytes or messages), > but on a buffer crisis (per connection or global) be able to tell the > sender to stop sending. I believe we rather should put our effort into a byte-oriented, TCP-like flow control, to permanently solve this issue. As said, it is on our agenda. > A few messages received while the sender is stopped could still be saved > (effectively assuming they were sent before the 'stop' was received). > > If running over an unreliable transport you'll want to retx the stop in > case it was lost. TIPC connections always run over a reliable media, - its own link layer. This means that the connection layer does not have any form of sequence numbering or retransmission, -it just assumes that everything arrives in order and without losses, as long as the link layer doesn't tell it otherwise. This isn't really a problem, as long as the connection-level flow control is able to work within reasonable constraints. That is what it is unable to do now, and what we are going remedy once our drive to redo the locking policy is finished. Regards ///jon > If the 'stop' message is an ack, then don't ack the last received message. > Then you'll get timeout recovery if the 'start' message is lost. > > David > > > -- 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
Powered by blists - more mailing lists