rfc:ien:ien177
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]
/data/webs/external/dokuwiki/data/pages/rfc/ien/ien177.txt · Last modified: 2001/06/25 20:37 by 127.0.0.1