Re: [IMRG] Requirements for IMP

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

jon bennett wrote:

> 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?) 
Jon,
For the use cases I can think about now, I'd say that the problems are 
rather separated, and being able to use the two schemes together is more 
a "nice to have" than a strong requirement. Therefore, if there's an 
argument for NOT using them together in favour of  bit saving and 
implementation simplicity (as you explain in the following) I think it 
should be seconded.

> > 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.
I also agree that it's not necessary to have a "TTL end" field in the 
header, as it only brings marginal advantages.

> 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. 
Just a clarification. Are you thinking of a generic mask or of a mask 
which always ends with a ones' string? (i.e. 00000001, 00000011, etc...)?
My point is that even if we could have a generic mask, I don't think 
it's useful. With a generic mask with X bits set to 1, the number of 
TTL values that are matched is equal to the number of  TTL values that 
are matched with the mask ending with X ones, but we "loose" the 
property that these matched TTL are equally spaced.
Example: (Immagine the TTL  is on four bit only, for simplicity)
- the mask 0011 would match with TTL = 3,7,11,15 (4 TTLs, equally spaced 
of 4)
- the mask 0101 would match with TTL 5,7,13,15 (always 4 TTLs, but not 
equally spaced)

> 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? 
See above, I think it's ok to use one of them at a time
Maurizio

>  


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