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]
