> On 12/16/09 10:10, Artem Kachitchkine wrote:
>
> > http://hub.opensolaris.org/bin/download/Project+npp/WebHome/cong-design.pdf
>
>
> Section 2
>
> Suppose A writes a cc module and puts it in /kernel/tcpcong/,
> does it mean that it will automatically be added in the next
> reboot (the text seems to imply it)? And if A wants to use
> it immediately, A needs to invoke `ipadm add-cong`? But what
> if A only wants to add it temporarily? I think most ipadm
> commands support -t flag. But if everything under
> /kernel/tcpcong/ is added automatically, there is really no
> such thing as -t. Can the design follow the ipadm model and
> does not add everything under /kernel/tcpcong/ automatically?
> When a cc module is installed, the installer should invoke
> ipadm to add that persistently. If it is not called, the cc
> module is not added and cannot be used.
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.
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?
perhaps it would be simpler to add one extra property:
ipadm set-prop -p cong+=algorithm protocol # adds algorithm to existing set
ipadm set-prop -p cong-=algorithm protocol # deletes algorithm
ipadm set-prop -p cong=algorithm protocol # current supported set will
# only contain algorithm
I think this might also work better with the "-t" option that Kacheong
mentions above. But that then raises the question of how to modify
cong-props as Kacheong describes:
> 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-..
>
> Since the kernel interface has a version, will add_cong
> return an error if the cc module version number does not
> match the kernel version?
*If* we are all in agreement that "cong" classifies as a valid
object type (I can easily see arguments against this, since this is
very tcp-specific, and an "algorithm" isn't intuitively an "object"),
then I suppose we coudl have an "enable-cong" and "disable-cong"
(ipadm has that concept for the other interface/address objects). That
would be another approach that would handle -t, and allow for a set-cong-prop.
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)
--Sowmini
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
