Subject: [IMRG] Requirements for IMP Checkpoint

From: jon bennett <[email-masked]>
Date: Wed, 10 Dec 2003 18:57:49 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/imrg

---

From: Matt Mathis <[email-masked]>
Date: Fri, 12 Dec 2003 01:27:39 -0500 (EST)

>     "keeping any eye on things" until something goes wrong.

There might be another issue to consider here: it might be possible to extend
IPMP to switches and other non-IP devices if the TTL match is used only as a
trigger.  Once triggered, every device (down to the scale of individual line
cards and switches) could (optionally) record information.  Complicated boxes
(large routers) could even timestamp more than once if there are multiple
queues within the box.   This would have to be an optional feature, but if 
you ever talk the likes of Intel and Syskonnect into doing it in standard NIC 
chips, then it will just happen everywhere....

(The hard part of this would be finding the IPMP header in a device that isn't 
really doing IP at all).

Just a thought.

Peace guys,

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
A good plan today is better than a perfect plan tomorrow.
	- Gen Patton

---

From: James Spooner <[email-masked]>
Date: Fri, 12 Dec 2003 23:00:45 +1300

> (The hard part of this would be finding the IPMP header in a device that
isn't

This isn't that hard, it requires buffering a small amount of packet inside
the switch
such that the checksum can be recomputed and spit out the other end.  I have
VHDL
an implementation of IPMP that is instanciated in Xilinx Virtex-II FPGA,
connected
directly to Two Level 1(Intel) 10/100Mbit Ethernet PHYs.  The biggest
problem with
our implmentation was that we had to re-compute the Ethernet Checksum
meaning we
had to buffer around 6 bytes of the packet, 2 for the IPMP pathp and
checksum calculation.

If you would like to see how we did it, I can (with permission from my boss)
make the code
available, our implementation follows the mcgregor draft.

Regards

James

---

From: James Spooner <[email-masked]>
Date: Fri, 12 Dec 2003 23:00:45 +1300

Regards

James

---

From: jon bennett <[email-masked]>
Date: Fri, 12 Dec 2003 10:07:05 -0800

>(The hard part of this would be finding the IPMP header in a device that 

I suppose I did ask for this (literally, in my first message :-) ) , but 
this is
of course quite a layering violation. It would be useful I'm sure, since an 
earlier poster mentioned detecting mismatched auto negotiate on ethernet 
links, I imagine the same problem would exist between layer 2 devices. But 
what do the layer 2 (1?) devices stamp for an address? and how do you send 
them an information request?

On a related point I would like to see firewalls, NATs and ALGs stamp the 
packet as well, but they pose the same problem of how do you address an 
info request to them.

jon