wayne@ultra.com (Wayne Hathaway) (01/22/91)
Can some expert out there please explain the relationship between IP
type of service (TOS) and TCP connection establishment? In particular,
1) Host A does a LISTEN() without specifying an IP TOS. Host B does a
CONNECT(TOS=THROUGHPUT). When host A sends segments to host B over
this connection, what TOS should it use?
2) Host A does a LISTEN(TOS=DELAY). Host B does the same
CONNECT(TOS=THROUGHPUT). When host A sends segments to host B over
this connection, what TOS should it use?
Another way of asking this is "Is TOS somehow negotiated during
connection establishment, or does each end use what it wants
independent of the other?"
Finally, for data transfer it would seem best for the end sending the
data to say TOS=THROUGHPUT and the end sending the ACKs to say
TOS=DELAY; is this typically done?
Thanx much.
Wayne Hathaway domain: wayne@Ultra.COM
Ultra Network Technologies uucp: ...!ames!ultra!wayne
101 Daggett Drive phone: 408-922-0100 x132
San Jose, CA 95134 direct: Hey, you!dab@BERSERKLY.CRAY.COM (David Borman) (01/23/91)
Wayne Hathaway writes: > Can some expert out there please explain the relationship between IP > type of service (TOS) and TCP connection establishment? In particular, > > 1) Host A does a LISTEN() without specifying an IP TOS. Host B does a > CONNECT(TOS=THROUGHPUT). When host A sends segments to host B over > this connection, what TOS should it use? > > 2) Host A does a LISTEN(TOS=DELAY). Host B does the same > CONNECT(TOS=THROUGHPUT). When host A sends segments to host B over > this connection, what TOS should it use? > > Another way of asking this is "Is TOS somehow negotiated during > connection establishment, or does each end use what it wants > independent of the other?" From RFC 1122, pg 107, 4.2.4.2: The TOS will be specified independently in each direction on the connection, so that the receiver application will specifify the TOS used ro ACK segments. My implementation of TOS follows this statement. Each side of the connection sets the TOS bits to what it wants; there is no automatic setting of the TOS bits in the listener based on the TOS bits of the received connect packet. So, for #1, Host A sends packets with TOS=0. For #2, host A sends packets with TOS=DELAY. > Finally, for data transfer it would seem best for the end sending the > data to say TOS=THROUGHPUT and the end sending the ACKs to say > TOS=DELAY; is this typically done? My implementation does not do that. For things like telnet & ftp, both sides use the same TOS value for the connection. Note that the area of TOS is one that is not clearly defined yet. The Host Requirements group decided to start making hosts set the TOS bits, to break the chicken and egg problem (you need both the hosts and the routers involved for it to do anything). The thing to do now is start implementing and experimenting with it, and as we gain experience with it, we can make new recommendations. -David Borman, dab@cray.com
barns@GATEWAY.MITRE.ORG (01/23/91)
Perhaps I can call myself at least a quasi-expert? Well, nothing says TOS is negotiated, except for the precedence, for which a negotiation is clearly described in the protocol spec. I think one can reasonably infer that each end does what it wants with the delay/throughput/reliability bits without regard to the other end. You probably already know that Host Requirements (RFCs 1122/1123) says to use TOS in accordance with recommendations in Assigned Numbers. If both ends did this, there should at least not be randomness, and under current recommendations, I believe there is no asymmetry. However, setting low delay on naked ACKs was discussed, and John Lekashman said it was a good thing and made performance better for his (NASA?) situation. The case in question was a high-bandwidth satellite path and a low-bandwidth terrestrial path. RTT was a bottleneck and finagling the TOS in this way allowed more data into the satellite pipe. Or something like that. I'd call it legal, possibly a desirable thing, but not common practice in vanilla software as far as I know. Bill Barns / MITRE-Washington / barns@gateway.mitre.org
jbvb@FTP.COM (James B. Van Bokkelen) (01/23/91)
Another way of asking this is "Is TOS somehow negotiated during
connection establishment, or does each end use what it wants
independent of the other?"
Current practice is to assign a TOS value to a given upper-layer protocol,
and use it for all packets (ack or data) related to that connection. Thus,
there isn't really any negotiation. One problem with using different TOS
values for two sides of a connection, or for acks vs. data, is that it
greatly increases the chance of asymmetric routing, which might affect RTT
estimation or even reachability.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901