[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEXT] offline Re: binary filters draft 0

On Thursday 07 May 2009, George Tsirtsis wrote:
> Hey Julien,
>
> I think what you propose is still difficult.
> This is already a very complex option given that all fields are
> optional and their presence is indicated by flags.
> Then at the end of the option we have pointers of which we can have
> many. Calculating the length of each of these is already tricky, but
> adding a 2nd type of pointer makes it even harder.
> How do you know which type of pointer it is? 

Two solutions, either 1) a pointer is typed with the first bit 
indicating its type (0 is byte-word-range, 1 is bit-pattern), or 2) we 
include two fields in the base header to indicate the number of 
byte-word-range pointers, and another to indicate the number of 
bit-pattern pointers.
 
> and how do you know the length of the 2nd one given your format?

The 2nd one has a fixed length since it only indicates matching on a 
pattern on one byte: 2(offset) + 1(mask) + 1 (value) = 4.

> Do you really think any of this is necessary or did the pointers idea
> just excited your imagination? :-)

Am I allowed to reply "both" :-)

Since I do not see the above as overly complex it could make sense to 
allow for possible future usages. But I would not insist if nobody 
thinks it's useful (and see below)

I've been searching and I found one that might or might not look 
realistic :-) 

Suppose we have an SCTP assocation running a multiple streams running 
inside, I'd like to be able to n-cast only the SCTP packets that 
contains only unordered data chunks, as indicated by the U bit within a 
data chunk:

      The (U)nordered bit, if set to '1', indicates that this is an
      unordered DATA chunk, and there is no Stream Sequence Number
      assigned to this DATA chunk.  Therefore, the receiver MUST ignore
      the Stream Sequence Number field.

> To be honest, the pointers are probably just a 'cool' thing that is
> likely to be used *very* infrequently. The only reason I came up with
> it is to remove the perception that binary filters are inflexible,
> when compared to Conny's text based filters.

Should we remove the pointers all together then?

--julien

> On Thu, May 7, 2009 at 3:15 PM, Julien Laganier
>
> <julien.laganier.ietf at googlemail.com> wrote:
> > On Thursday 07 May 2009, Julien Laganier wrote:
> >> > Hi Julien,
> >> >
> >> > This is not a bad idea. We are increasing complexity though. One
> >> > thing that bothers me with bit based pointers is byte alignment,
> >> > which can no longer be assured.
> >> >
> >> > I think we should be careful not to go crazy with these.
> >> > Pointers, in their current simple form, already give increased
> >> > flexibility to the binary filters.
> >> >
> >> > If this flexibility proves insufficient some time in the future,
> >> > we can always come back and define another flow description
> >> > sub-option that it either allows for more complex pointers or
> >> > offers more flexibility in some other way.
> >> >
> >> > For now, I would prefer to keep it relatively simple.
> >> >
> >> > Thoughts?
> >> >
> >> > George
> >>
> >> Hello Georges,
> >>
> >> You're right - this one-size-fits-all pointer is way too complex.
> >> How about defining two pointers, a "bit pattern" to match on some
> >> bits on a byte boundary, and a "byte-word-range" one to match some
> >> byte-aligned field on a range basis.
> >>
> >> Rough strawmans would look like:
> >
> > Of course I messed up the second one for bit mattern, see an update
> > below.
> >
> >       0                   1                  
> > 2                   3       0 1 2 3 4 5 6 7 8 9 0 1 2 3
> > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
> >            |           Offset              |  
> >  Length     |    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |      Start Value ...                      
> >                    |    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |               |         End Value ...    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                              Figure 2a: Byte Word
> > Range Pointer
> >
> >       0                   1                  
> > 2                   3       0 1 2 3 4 5 6 7 8 9 0 1 2 3
> > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
> >            |           Offset              |  
> >  Mask       |    
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |   Value       |
> >     +-+-+-+-+-+-+-+-+
> >
> >                              Figure 2b: Bit pattern
> > Pointer
> >
> > --julien



-- 
--julien