So, a followup question to the concerned citizenry... if this does become the subject of an RFE, what *exactly* should the desired semantics be?
Option 1: If the TOS bits on the listening socket are null (ie havent been previously set), 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. 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. Option 3: As above but the knob is system-wide, settable via ndd or in /etc/system. Pros and cons apparent. Other?? Survey says? -----Original Message----- From: James Carlson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 08, 2007 11:00 AM To: David McDaniel (damcdani) Cc: [email protected] Subject: RE: [networking-discuss] Basic question re timing of SYN/ACK David McDaniel (damcdani) writes: > RE: " You shouldn't have to set anything. The system should copy the > TOS > (DSCP) bits from the original SYN to the new 'eager' socket, so they > should be there when you accept." > Alas, its uglier than that. There are some emerging applications > where for various reasons the DSCP bits are being re-used for policy > decisions through firewalls. > Today, when a DSCP-marked SYN comes in, the SYN/ACK gets sent back > out without echoing the bits and thus never gets through the firewall > and the connection attempt therefore fails. Ugly. That sounds like a fatally broken firewall. The bug is in the firewall software, not the client that is reasonably following the RFCs. > So not only would it be nice if the TOS bits could be copied into > the new socket on accept(), the should also (at least optionally) be > echoed at handshake time. Yes, as I said in a follow-up, that'd be a good RFE. Arguably, that behavior could even have been the default, but the current model for sockets (in general) is that the sender gets to pick what DSCP bits make sense to him, based on his local configuration. I think that this is just a subset of a larger problem, which is that the sockets interface doesn't do much with QoS. I think that actually represents a lack of substantial application involvement in those features, rather than a failing in sockets. -- 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]
