David McDaniel (damcdani) writes:
> Option 1: If the TOS bits on the listening socket are null (ie havent
> been previously set),
"null?"
The default is 0. Are you drawing a distinction between "the default"
and "intentionally set to 0 by the application?" If so, then I don't
think that's a good direction to go; it's needlessly complex.
> copy the bits from the SYN into eager's TOS
> unconditionally, otherwise keep the listener's settings. This is
> probably what most people would want to do, but precludes the listener
> from from setting initial defaults different from what the system might
> set.
I'm not sure I understand the value of this option, and it seems to
conflict with (be incompatible with) the existing behavior.
> Option 2: If the TOS bits in the incoming SYN differ from what the
> listener has, AND a newly introduced option like TCP_COPY_TOS or
> something is requested, copy the bits from the SYN into eager otherwise
> copy the listeners bits. This probably the most expressive, allowing the
> developer to specify precisely what is to happen in all circumstances,
> but requires the introduction of yet another option. I hate the idea of
> introducing application layer knobs that are almost never used, churning
> headers, etc.
I prefer this one.
> Option 3: As above but the knob is system-wide, settable via ndd or in
> /etc/system. Pros and cons apparent.
No. Unless there's a really compelling reason to do this, I would be
fairly strongly opposed to a system-wide (or even zone-wide) setting.
It's too much of a hack, and will just get harder to support over
time.
If we really need something like this (due to applications that can't
be changed), then I'd prefer to see a mapping. We need mappings
anyway. The obvious one looks like this:
{socket_tos,SYN_dscp} -> {selected_dscp}
... deliberately leaving out the ECN bits, on the assumption that they
"just work." Of course, it could be masked as well, to provide
finer-grained control. A more elaborate scheme would be:
{uid,gid,pid,projid,zoneid,ctid,ifIndex,socket_tos,SYN_dscp} ->
{selected_dscp}
This would allow us to have extremely fine-grained control over the
way TOS/DSCP values are mapped, so that applications and zones and
projects and the rest could map to desired values on the wire. I
think this (plus some DS boundary mapping capability) is the right
sort of direction to go.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
