On Tue, Jun 11 2019, Olga Kornievskaia wrote:

>
> Neil,
>
> What's your experience with providing "nosharedtransport" option to
> the SLE customers? Were you are having customers coming back and
> complain about the multiple connections issues?

Never had customers come back at all.
Every major SLE release saw a request that we preserve this non-upstream
functionality, but we got very little information about how it was being
used, and how well it performed.

>
> When the connection is having issues, because we have to retransmit
> from the same port, there isn't anything to be done but wait for the
> new connection to be established and add to the latency of the
> operation over the bad connection. There could be smarts added to the
> (new) scheduler to grade the connections and if connection is having
> issues not assign tasks to it until it recovers but all that are
> additional improvement and I don't think we should restrict
> connections right of the bet. This is an option that allows for 8, 10,
> 16 (32) connections but it doesn't mean customer have to set such high
> value and we can recommend for low values.

The current load-balancing code will stop adding new tasks to any
connection that already has more than the average number of tasks
pending.
So if a connection breaks  (which would require lots of packet loss I
think), then it will soon be ignored by new tasks.  Those tasks which
have been assigned to it will just have to wait for the reconnect.

In terms of a maximum number of connections, I don't think it is our place
to stop people shooting themselves in the foot.
Given the limit of 1024 reserved ports, I can justify enforcing a limit
of (say) 256.  Forcing a limit lower than that might just stop people
from experimenting, and I think we want people to experiment.

NeilBrown