Re: [IMRG] Requirements for IMP

[Maurizio Molina <molina@ccrle.nec.de>]

Matthew Luckie wrote:

> > > 2) Length of Measurable Path
> > >
> > > Is it a requirement of IMP to be able to measure paths of any length?
> > > If the path works (as opposed to loops) then we would want to measure
> > > all of it regardless of length so the answer would seem to be "Yes".
> > >
> > > An implication of this is that for small packet sizes and/or reverse
> > > path measurements some method of preventing the first N hops from
> > > always filling the packet is needed, otherwise only the first N hops
> > > will ever be measurable.
> > >      
> A comment on this, taken from our IMW2001 paper:
>
> http://www.icir.org/vern/imw-2001/imw2001-papers/85.pdf
>
> "The minimum packet size that must be supported by an IP network, 576
> bytes, allows for 45 path records to be stored in an echo request packet.
> The size of the path record would increase to 24 bytes in an IPv6
> environment due to the storage requirements of a 16 byte address.
> In an IPv6 environment, the Minimum Transmission Unit (MTU) of 1280 bytes
> [RFC 2460] allows for 50 path records to be inserted in an echo packet.
> Research from CAIDA's Skitter project
>
> http://www.caida.org/tools/measurement/skitter/RSSAC/
>
> indicates that the average distance between the F root server (at ISC in
> 1999) and a  customer of that server is 13 hops, while less than 0.5% of
> paths are longer than 22 hops.  For a path connecting a pair of hosts that
> is longer than can be measured with the MTU-sized packet, a measurement
> host may restart the measurement from one of the last IP addresses in the
> path record by sending an echo request
This I didn't understand. Does the current protocol specification allow 
to start the measurement from an arbitrary point of the path? This would 
of course (almost) solve the problem we're discussing about....  
> to an address that will answer the
> request (if there is such an address), or by sending a larger packet if
> the underlying network supports the increased size of the packet."
>
> so i'd respond that this feature is not something that is necessary.  In
> practice, I'd imagine the vast majority of paths can handle more than 576
> bytes.
>
> http://www.netsys.com/ietf/1994/1280.html
>
> You can fit about 120 IPv4 path records in a 1500 byte IP packet.
The numbers you brought are convincing that there'll be room for path 
records in "the vast majority of the paths" (we then may discuss whether 
this is enough, and I would agree that yes, it is enough and not worth 
complicating the protocol for that reason only...).
However, in my previous message I brought two other reasons for which 
the flexibility of selectively letting a router fill in a path record 
could be useful, namely 1) the possibility of discovering "bad" IPMP 
implementations and 2) reducing the measurement load brought by non 
congested paths.
Could you comment on these?

> > As regards the implementation of such a selection, one can immagine
> > different possibilities, trading off simplicity and selectivity.
> > E.g. putting two explicit 1 byte start/end indexes in the IPMP header
> > (an IPMP router can write a path record only if the TTL of the packet is
> > within the range) or using a very few bits (an IPMP can write a paket
> > only if the TLL ends with the same bit pattern).
> >    
> other approaches include laying out path records which are blanked out
> except for the TTL field, which are set to whatever TTLs you're interested
> in.
Once again I didn't clearly understand this, sorry. Are you suggesting 
that the path record format can be NOT fixed (i.e.12 bytes IPv4, 24 
bytes IPv6)? Then where is the lenght of the path record encoded? I 
think that Jon brought up exactly this point in his original message of 
this thread: It was "5) Timestamp in Path Record"

> I don't think this buys us anything, the whole "tightly constrained and
> easy to implement" argument goes out the window, and becomes non compliant
> with point 12 of RFC 1925
which is always a good rule to follow, provided pro and cons of 
adding/excluding features have been discussed....
Maurizio

> > My understanding of the role of the Information Request in
> > http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-03.txt
> > is that it  is  used to get better confidence of what the echo request
> > packet carry. There's no reqirement for Information Request to be
> > processed like ordinary data packet, and in sec. 4.5 it's said that a
> > rate limitation or a low processing prioriy can be used as a protection
> > from potential DoS attacks exploiting the Information Request.
> >    
> This is correct.
>
>  
> > I agree, however, that the protocol should not make Echo Requests depend
> > on Information Request, i.e. the protocol should work anyway in absence
> > or with a low rate of Information Requests (but an application could
> > then declare the measurements as "unreliable").
> >    
> The utility of the Information Request is largely underestimated.  The
> protocol will largely work, although you'll be without some useful data.
> We're working on expanding the information request section for -04.txt to
> better illustrate the usefulness of it.
>
> Matthew
>  


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