[IMRG] Requirements for IMP Checkpoint

[jon bennett <jcrb@yahoo.com>]

Ok so its been about 3 weeks since I posted the first list of requirements. 
There were comments/disagreements on some of the points and silence on 
others. I am going to indicate which points I feel there was no indication 
of disagreement on so that I can go on to the next set of requirements. For 
those where there was disagreement I will try to summarize the different 
views so that others can indicate a preference if they have one.


----------------------------------------------------------------------
Requirements without objection

1) Measurement of the Reverse Path

   IMP must be capable of measuring reverse paths


3) Host Processing, Raw Sockets or Ports

   IMP packet should contain port numbers for use by end system OSes
   (separate from the faux-port number for matching flow filters)


4) IP Address in Path Record

   Path records are not required to contain globally routable IP addresses


5) Timestamp in Path Record

   Path records are not required to contain timestamps


6) TTL in the path record

   TTL must be included in path record


7) Information Request

   Info Request can not be required for operation of the protocol
   (this is also dictated by point 4, you can't send an Information
    request to a device you can not address)

9) Redirection

   IMP must support the ability to redirect an IMP packet,
   similar to the IP loose source route option, but within
   the IMP packet rather than with IP options.


----------------------------------------------------------------------
Requirements without requested feedback

8) Information Request part of IMP or a UDP Based Service

   No comments on this. Could people indicate if the ability to use
   the IMP redirection feature to send Information Requests to routers
   on a broken reverse path is important enough to have the Information
   Request be carried in an IMP packet as opposed to a UDP packet? Since
   except for that one particular case I don't see any other issue that
   prevents the Information Request from being a regular UDP packet.


----------------------------------------------------------------------

Requirements with objection

2) Length of Measurable Path

   Should IMP provide a mechanism for measuring long paths
   or measuring paths using small packets.

   I think that it should.

   Matthew thinks that an 8 bit compare is too much added complication

   Maurizio thinks that it should also include a method of measuring
   some controllable fraction of the hops.

   I would agree with Maurizio's view as well, although I think that in
   todays commercial Internet a method which measured the devices on the
   boundary of an AS might be a more useful, in the case where one is just
   "keeping any eye on things" until something goes wrong.


5) Timestamp in Path Record

   There is disagreement as to whether 'blank' timestamps should be
   included in path records or if they should be left out by devices
   which do not include them, or which have been asked not to include
   them (if such capability existed). If IMP is not being used for
   timing but just for path identification then dropping the timestamp
   yields a 50% increase in the number of records that fit in a packet.
   It also reduces the number of data copies and checksum additions
   the device is required to perform where the user indicates they
   don't want a timestamp in the path record and the device would
   otherwise have included one. From prior conversations I am pretty
   sure that Matthew thinks the gain is not worth the effort.



_______________________________________________
IMRG mailing list
IMRG@ietf.org
https://www1.ietf.org/mailman/listinfo/imrg