Some belated comments.
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.
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?
Section 5.1
Is tcpcong_load() called only once when TCP/SCTP wants to
use a cc module? Does this mean that TCP/SCTP needs to
keep a counter on the number of conn/assoc using a particular
cc module. When all those conns/assocs are gone, the
tcpcong_unload() can be called. Or does the design require
that once a cc module is loaded, it should not be unloaded,
except maybe until the netstack is going away? Or is
tcpcong_load() called for each TCP conn/SCTP assoc?
Since a cc module may not support both TCP and SCTP, should
we have a protocol argument to tcpcong_load()? Otherwise,
TCP/SCTP cannot know if the cc module is OK to use until
maybe when it calls co_state_size().
How does tcpcong_load() report an error, say cc module not
found?
It seems that the current design requires a different cc
module binary for different interface version. Is it
difficult to change it so that one cc module binary can
support multiple interface versions (assuming the algorithm
allows that)? And depending on the kernel cc interface
version, the binary can export different tcpcong_ops_t.
Just wondering.
5.2
Will co_state_size() return 0? Or does 0 mean error?
What does TCP/SCTP need to set in tcpcong_args_t when
callng co_state_init()? Just the ca_state? If this is true,
why not just pass in ca_state directly? In general, please
describe all the in/out parameters for each ops.
What is the need to have co_enter_fr() since it will be
called immediately after calling co_loss(TCPCONG_DUPACK)?
And the current design seems to suggest that between fast
retransmit and end of fast recovery, TCP/SCTP will do its
own stuff and only after that, the cc module will take
control of the cwnd again. What if there is a cc module
which wants to do something here also?
If TCP detects that a retransmission is spurious, say by
F-RTO, is there a call to notify the cc module?
ICMP Source Quench is dead. I guess we may exclude it.
There is not an idle time field in tcpcong_args_t. Should
there be one as the cc module may want to change the cwnd
according to how long the idle time is?
5.3
What is the use of ca_ssthresh? The threshold is normally
checked when setting cwnd. But the cc module already has
complete control on the cwnd. Should TCP/SCTP care about the
value?
Does ca_bytes_acked == 0 serve the purpose of dup ack
notification to the cc module?
5.4
If A have already written a cc module for Linux, what needs
to be done to port it over? This section suggests that the
interface is actually quite different. I guess adding some
guidelines/explanation on the differences is a good idea.
--
K. Poon.
kacheong.p...@sun.com
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
