WRT "null?"... I meant defaulted, as in zero. But I hadnt considered the case of explicitly set to zero.
From the developer perspective I actually prefer #2 also, because it lets me do precisely what I want done on a per-socket basis. My complaint about introducing a seldom used option is from the certain knowledge that over the years these bits add up and you can never (or hardly ever at least) get rid of them. -----Original Message----- From: James Carlson [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 2:03 PM To: David McDaniel (damcdani) Cc: [email protected] Subject: RE: [networking-discuss] Basic question re timing of SYN/ACK 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]
