Re: [IMRG] Requirements for IMP

[jon bennett <jcrb@yahoo.com>]

Maurizio,

> the scheme you propose is probably the one that gives the maximum 
> flexibility with the minimum number of bits in the header (3).
The number of bits in the header is not a big deal at this stage. What I 
was first trying to do was better understand what were the problems you 
wanted to solve, and then once it is clear what the problems are it is 
easier to look at possible ways to solve those problems. As I understand it 
you have two separate concerns. The first is to monitor the whole path 
without having to monitor every single router on the path. It sounds like 
you think the 'every (2^N)'th router' approach addresses that concern.

Then you have a second problem to solve which I think is unrelated to the 
first one. (Is that a safe assumption? Or is there any chance they are 
related, and that you would need to do both at once?)

> However, in case you're intrested in measuring what happens on a set of X 
> routers close to each other (i.e. on a sequence of next hops), AND these 
> routers are far from the source (or on the reverse path) AND  you have a 
> IPMP packet constrained in size,  you may have (in the worse case) to use 
> X packets to let  each of these X routers fill the packet (playing with 
> the TTL as you showed). Beyond having to spend X packets, you'll never be 
> able to have in the same packet the timestamps of all these X neighbouring 
> routers, which may be a limitation.
> An example (numbers are only for the sake of clarifying what I mean): 
> suppose your IPMP pkt can only contain 10 records and you're interested in 
> measuring
> routers at "position" 21,22,23 along the path.
In my draft one of the IMP header fields is called "Start TTL", and its use 
is to delay the insertion of path records as long as the TTL value is 
greater than the Start TTL value, so if you wanted to measure routers 
21,22,23 you could set the Start TTL to 235, and you would then only get 
records from 21,22,23,  plus however many more records fit in the remainder 
of the packet. Does it matter if you have records inserted after the 
routers you are interested in? If it doesn't matter then you would not need 
to have a Stop TTL, just the Start TTL. Now if you really don't want any 
more records in the measurement that could be done without needed any more 
header fields. You could set the value of the "Path Pointer" to be "Packet 
Length" - "Size of 3 Path Records" so that the packet filled up after you 
got the three records you wanted.

> With 19 bits (start and end index + the 3 bits you suggested) we have 
> probably all the flexibility we need.
> I'm not pushing right now for one schema or the other, just wanted to 
> point out that nothing comes for free...
Now if it was acceptable to do the trick with setting the Path Pointer so 
that the packet filled up then you would only need 11 bits, 3 for the 
2^N'th skipping and 8 for the Start TTL. The reason I asked before about 
would you need to do both of these at once is that if you didn't then you 
could reuse the Start TTL bits when you wanted to do the 2^N'th skipping 
and then only need 9 bits (8 for the Start TTL and 1 bit to tell you which 
function it was implementing). The other benefit of reusing the Start TTL 
field for this purpose would be that instead of making the router make a 
mask from 3 bits you could just make the sending host put the mask in the 
Start TTL field (which would have to be renamed something like TTL Select, 
having more than one use now), that way the router could just AND the TTL 
Select field with the TTL rather then having to generate a mask first and 
then AND it.

I think skipping to every 2^N'th hop would be quite useful, particularly 
for size constrained packets like VoIP where recording every 4'th router 
would let you monitor a path up to 40 hops long with a single packet (In my 
draft there is a flag in the header which lets you collect path records 
only on the forward or backward path so you could use all 10 of the records 
in a G.711 VoIP packet for one direction).

So I think both mechanisms have there uses, my question would be do you 
need to be able to use both at once? or is it ok to only be able to use one 
of them at a time? 

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