Responding separately regarding ipadm interfaces.
On 01/14/10 11:04 AM, Kacheong Poon wrote:
>
> Is there a need to have a set-cong-prop command to change
> some cc algorithm's behavior? For example, we may want to
> be able to change max increment of cwnd for CUBIC. If we
> have set-cong-prop, we should have show-cong-prop and reset-..
I thought about that. Given our past experiences with private driver
properties (which this is quite similar to), I came to the conclusion
that it might not be worth the effort. That is, the usefulness of having
stable administrative interfaces for private cong module properties is
overweighted by the cost of implementation and ongoing maintenance. I
figure that folks wanting such low level of control wouldn't mind
setting tunables directly (via mdb or /etc/system).
On 01/15/10 07:02 AM, sowmini.varad...@sun.com wrote:
To add to this further, I think the proposal in Section 2 is a
significant departure from the <verb>-<object> syntax that is
being carefully enforced for all the other dladm/ipadm sub-commands.
"cong" is used as an object-type in the proposed "ipadm add-cong"
syntax, and it is used as a property in the "ipadm set-prop -p cong=.."
syntax. We've got to go with one or the other.
Hmm, I haven't thought of it that way. It's nice to consider more than
one point of view.
Further, could you please clarify exactly what the registration
process in "add-cong" does, esp if (as the subsequent paragraph documents)
all congestion algorithm are automatically registered?
As I noted previously, modules are not automatically registered by
placing them in /kernel/tcpcong. add-cong is supposed to be invoked as
part of package installation, just like add_drv(1M) is invoked when
driver packages is installed. And therefore there is no "-t" problem
either, algorithm registration is always persistent.
perhaps it would be simpler to add one extra property:
ipadm set-prop -p cong+=algorithm protocol # adds algorithm to existing set
"cong" right now means the default algorithm, so this specifically
wouldn't work, since there can only be one default. But I get your idea
to use a string-array property for registered algorithms, e.g.:
ipadm set-prop -p cong_all+=algorithm protocol
ipadm set-prop -p cong_default=algorithm protocol
It is definitely worth consideration. I need to think a bit and verify
whether this is functionally equivalent to the <verb>-cong scheme, and
if it is, I'd have no problem switching to your scheme. You know I'm all
about making everyone around me happy :)
One other question that I had when reading the document- Section 1 states
that "there is no one algorithm that will work well for every possible
network". So would the algorithm choice then depend on the outgoing
interface? the outgoing gateway? the connection destination?
(since the actual path taken to the destination is non-deterministic,
I can see all of the above as impacting factors that an admin might
want to use as constraints)
Yes, I can think of various heuristics for the system to select an
algorithm automatically. Right now we only provide the per-zone
granularity, but foresee further improvements in the future. This is
more of a project management decision than an architectural, we just
want to get this out there ASAP, so we can start collecting feedback
from the users with a variety of links and workloads; we can only go so
far with lab simulations. Note however, that this is only a limitation
for congestion-unaware applications - each process is free to switch
between algorithms arbitrarily using the {TCP,SCTP}_CONGESTION socket
option.
-Artem
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
