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

                        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

      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

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

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.


   [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]