Hi Simon,
3.4. The additional fields for the result of SCTP_GET_PEER_ADDR_INFO
are only a small subset of the information in tcp_info, although one
could see almost all the fields in tcp_info being equally applicable
to SCTP. Wouldn't it make sense to just add the entire set?
That's how SCTP_GET_PEER_ADDR_INFO is defined in the IETF draft, we
can't change it at this point. But we could introduce a new option, if
need be.
4. Security Considerations: I'm fine with the current proposal to let
all processes use all congestion control algorithms that are loaded
in the system. You say that "ipadm remove-cong" is a big hammer if
one want to restrict algorithm - that's true because it's
system-wide. It would be nicer if it could be done in a zone-wide
manner, but I guess there is no mechanism for restricting the
visibility of such loaded modules to specific zones.
ipadm remove-cong won't physically remove the module, so module
visibility across the zones is not an issue here. Technically, we could
add finer controls, question is, is it worth the effort.
6.3. I'm not sure it's true that cwnd transition events are only of
interest to kernel developers, testers, and congestion control
researchers. I could see this information being used by performance
engineers trying to understand throughput issues, correlating packet
traces with events. So if a user-friendly dtrace interface could be
found for this, that might be nice.
Right, and as the document mentions, traffic capture can give a pretty
good approximation based on how many segments the sender injects into
the pipe without waiting for acks, though it's not perfect. The DTrace
tool will be widely available as part of the test suite for those who
want it, but perhaps it is not worth the effort to integrate it into the
OS product.
The above three points have this in common: we _could_ add all the
nice-to-have's to the feature list, but then we'd never finish the
project (and when I say "we" it is really just "me" :) Certain features
must be delivered now; others can be postponed until later, when we have
more experience and feedback from the field; and yet others can be
disseminated by other means like opensolaris.org and blogs and BigAdmin.
-Artem
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
