J. Postel
IEN 177 ISI
24 March 1981
Comments on Action Items from the January Meeting
At the recent Internet Meeting a number of issues were raised as "action
items" [1]. Many of these can be resolved fairly simply. This note
describes the resolutions I propose. These topics may be further
discussed at future meetings or via IENs. Your comments are requested.
Action Items from RSRE:
1. Dynamic timeouts for retransmission in TCP.
Yes. The algorithm described by RSRE at the October 80 meeting
should be implemented. It will be included in the next edition of
the TCP specification.
The current best procedure for retransmission timeout is to
measure the time elapsed between sending a data octet with a
particular sequence number and receiving an ack that covers
that sequence number (thus one does not have to match sends and
acks one for one). Using that measured elapsed time as the
round trip time (RTT), compute a smoothed round trip time SRTT
as:
SRTT = ( ALPHA * SRTT ) + ( (1-ALPHA) * RTT )
And based on this, compute the retransmission timeout (RTO) as:
RTO = min[ BOUND, BETA * SRTT ]
Where BOUND is an upper bound on the time-out (e.g., 30
seconds), ALPHA is the smoothing factor (e.g., .8 to .9), and
BETA is a delay variance factor (e.g., 1.3 to 1.5).
2. Flag bit for copied options in IP fragments.
Yes. This makes good sense and will be done in the next edition
of the IP specification.
The option type octet is viewed as having three fields:
1 bit: copied flag (0=do not copy, 1=copy)
2 bits: option class
5 bits: option number
Postel [Page 1]
IEN 177 Comments on Action Items from the January Meeting The options affected are: security, source routing (loose & strict), and stream identifier. 3. Specification for strict source routing. Yes. In the next edition of the IP specification there will be two options: Loose Source Routing (LSR) and Strict Source Routing (SSR). LSR will be the source routing currently specified which allows arbitrary internet routing between the listed addresses. SSR will have the same syntax, but will require that the next listed address be the next internet node visited (where "internet node" is a gateway or host), and that it be accessed via the net in the listed address. 4. Standard addresses for Echo, Discard, and Character Generator servers. These already exist. Assigned Numbers [2] lists ports for both UDP and TCP servers as follows: PORT SERVER ---- ------ 7 Echo 9 Discard 19 Character Generator 5. Techniques for preventing Silly Window Syndrome (SWS). I am not sure we fully understand this yet, but it is clear that very small window updates aggravate the situation. The next edition of the TCP specification will include words of caution about small window updates. Perhaps it should say "don't update the window unless the additional space exceeds X percent of the total buffer space for this connection". Any suggestions for the value of X? The sender can also try to stay out of SWS by only sending big segments and waiting until the window is large enough to allow it. If the sending user indicates an end of letter then the data must be sent even if it is a small segment. At the same time we don't want to delay the acknowledgment, so when a small segment arrives and is accepted, the typical response should be to send an acknowledgement without updating the window. It is also thought that the probing of a zero window with an octet Postel [Page 2]
IEN 177 Comments on Action Items from the January Meeting of new data may lead to SWS. Some consideration of probing with the most recent octet of old data is in order. It is not clear that this can be done reliably (does it matter?), or that an "old data" probe will elicit new window information. 6. No changes to addressing for a while. I am not sure we can do this. There is clearly a need to provide for a large number of networks in the future. Vint's proposal for alternate ways of cuttting up the 32-bit internet address may be included in the next edition of the IP specification. high order bits format --------------- ------ 0 7 bits of net, 24 bits of host 10 14 bits of net, 16 bits of host 110 21 bits of net, 8 bits of host 111 escape to extended addressing mode A value of zero in the net field means this net. The extended addressing mode is undefined as yet. Action Items from NDRE: 1. A HDLC port on the SATNET gateway is needed. A problem for Vint and BBN. 2. ARPANET availability must be improved. A problem for Vint and DCA and BBN. Action Items from MIT: 1. A maximum segment size TCP option is needed. Yes. This can be included in the next edition of the TCP specification. The syntax will be the same as the existing Buffer Size option. Action Items from DCEC: 1. How do we provide testing facilities to companies that develop TCP products? A problem for Vint and DCA. Postel [Page 3]
IEN 177 Comments on Action Items from the January Meeting 2. How do we control transit traffic? This is a difficult problem, and I only promised answers to the easy ones. Right now the only information available for an IP gateway to base a decsion on is the stuff in the IP header (source and destination address, protocol, tos, security). In the current situation, my approach would be to have a gateway that cares about restricting transit traffic to have a list of approved sources and have it simply discard and datagram from a source not on the list. Action Items from BBN: 1. Rubber EOL and Buffer Size has implementation impact in TAC. My understanding of this is that implementation of TCP in the TAC is purposely not capable of handling rubber eol. A survey of some implementers indicates that no implementaion sends the buffer size option. This means that rubber eol never occurs. Vint suggests deleting the buffer size option. This implies that all the rubber eol stuff can go away. I am prepared to delete the buffer size option and all references to the rubber properties of eol from the next edition of the TCP specification. What do you say? Questions from SDC: 1. Who supplies the "protocol" field for the IP header, IP or the transport protocol? This is an implementation specific issue. In the simplest case the IP just dosen't care what the protocol field says so the upper level protocol can supply it on each call. In a more controlled operating system environment the IP would fill in the protocol field in the individual datagrams sent based on some initial set up call from the upper level protocol module which supplied the value at that time. 2. What is the nature of the interaction between IP and GGP? The nature of the interaction between IP and GGP can only be described as friendly. Actually, at the meeting I discussed a set of messages that combine the messages gateways send to hosts and messages that hosts send to hosts about problems with datagrams [3]. The plan is to establish this as a separate control protocol for IP. The interaction between the control protocol module and the IP module would be very intimate -- they would be the same module. Postel [Page 4]
IEN 177 Comments on Action Items from the January Meeting 3. Is source routing loose or strict? Both. The current IP specification of the source routing option is for the loose source routing. A similar option for strict source routing will be documented. Question from BBN: 1. How does IP interact with the local net, on errors, on flow control, etc.? Since IP is supposed to work with such radically different local nets it is not clear there is an answer to this question. Whatever information the local net hands back to the IP about errors (e.g., non-delivery) should be communicated to the source of the datagram. Question from ISI: 1. What is the size and precision of time stamps used in internet measurements? What is time zero? One proposal is the number of milliseconds since midnight 1 January 1980 GMT modulo 2**32, in other words the low order 32 bits of that value (32 bits of milliseconds is approximately 49.7 days). The IP Timestamp Option now simply says it is 32 bits of milliseconds, failing to mention what time zero is, or indicating in any way who did the stamping. I propose to change the option to include the internet address of the stamper and to specify time zero as 1 January 1980. This will make the option 10 octets long and allow at most 4 stamps in a datagram header. There is also no way to indicate what datagrams are to be stamped. Possibly the "stamper addresses" should be filled in by the source to indicate which internet modules (gateways or hosts) are supposed to fill in times. Action Item for ISI: 1. A NIFTP-MAIL/MTP interface data structure should be defined soon. Actually, this is a host specific issue of defining the internal stored format for queued mail for multiple recipients. This format may be used by both MTP and NIFTP-MAIL as well as a number of user interface programs. ISI is working on it for TOPS20. Postel [Page 5]
IEN 177
Comments on Action Items from the January Meeting
Question from ARPA:
1. There is a open question about mailbox addresses and the problem
of sending (and answering) mail to (from) mailboxes in other systems
(e.g., Internet, TELEMAIL, ONTYME).
The quick answer seems to depend on making another systems
structured address be one field in your own systems structured
address. Even so automatic derivation of reply addresses is hard.
Otherwise this is a tricky problem.
References
[1] Postel, J., "Internet Meeting Notes -- 28-29-30 January 1981",
IEN 175, USC/Information Sciences Institute, March 1981.
[2] Postel, J., "Assigned Numbers", RFC 776, USC/Information
Sciences Institute, January 1981.
[3] Postel, J., "What Every Host Should Know About GGP",
USC/Information Sciences Institute, January 1981.
Postel [Page 6]
mirror server hosted at Truenetwork, Russian Federation.