Subject: Re: [MEXT] binary filters draft 0

From: Christian Kaas-Petersen <[email-masked]>
Date: Tue, 5 May 2009 14:13:32 +0000 (GMT)

The DSfield is fine.  But for the ECN, using the general offset
mechanism, the offset is a count of bytes from the beginning of the
packet, and the length is a number of bytes, so I cannot see how it
should be possible to consider two ECN-bits somewhere in the middle
of the packet when the neighboring six bits in general can take
any values.

Christian

--- Den tirs 5/5/09 skrev George Tsirtsis <[email-masked]>:

> Fra: George Tsirtsis <[email-masked]>
> Emne: Re: [MEXT] binary filters draft 0
> Til: "Christian Kaas-Petersen" <[email-masked]>
> Cc: [email-masked]
> Dato: tirsdag 5. maj 2009 12.18
> Christian, et.al.,
> 
> As I was implementing the changes discussed earlier, the
> following
> issue came up.
> 
> One of your comments is about renaming the TOS field to
> DSCP. First of
> all I noticed we used the term Class of Service (CS) in the
> IPv6
> header which is not correct...instead it is Traffic Class.
> 
> Looking into this a bit more, however, I remembered that
> the IPv4 TOS
> byte as well as the IPv6 TC byte were redefined as 6bit
> DSfield and 2
> bit Currently Unused (CU) fields. One of the CU bits was
> then used by
> ECN (see RFC3260 for all this).
> 
> Since I do not anticipate anyone to be matching the ECN bit
> for the
> purpose of Flow Bindings, I suggest we redefine the 8-bit
> TOS field as
> an 8bit DSfield, the last 2 bits of which MUST be set to 0
> by sender
> and ignored by the receiver. This way a given DSCP can be
> matched
> without getting confused by the ECN bit.
> 
> If someone really wants to match the ECN bit, (who knows
> why) of
> course they still can, by using the offset based pointers
> defined in
> the draft.
> 
> Note that I do not want to make this a 6bit field because
> that would
> break byte alignment for the sub-option, when this field is
> present..
> 
> Does this make sense?
> 
> George
> 

      Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 5 May 2009 15:35:27 +0100

Ooops yes, you are right, So the ECN 2bit field cannot be identified
by pointers, as they are currently defined.
I still think though that there is no need to ever match on ECN bits
for flow bindings...so we are probably OK?

I guess the more general question is, do we need the pointer to be bit
specific? or byte specific is enough?

George

---

From: Julien Laganier <[email-masked]>
Date: Wed, 6 May 2009 17:10:46 +0200

Hello George,

On Tuesday 05 May 2009, George Tsirtsis wrote:
>
> I guess the more general question is, do we need the pointer to be
> bit specific? or byte specific is enough?

If doable, I think it would make sense to be able to match pointer on 
bit-boundaries rather than byte-boundaries. Another thing that could 
make sense is the ability to specify the value of pointers in terms of 
ranges. What do you think?

FWIW a strawman pointer could then look like:

      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                              |R|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Length  |     Start Value ... 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               | End Value ...
     +-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 2: Pointer

   Offset

      The Offset field identifies an integer number of bits from the
      beginning of the IP header.  It points to the beginning of the
      field of interest in the packet.

   R (Range)

      The R flag indicates whether the pointer is to a value (unset, 
      zero) or a range of values (set, one.)

   Value Length

      The Value Length field identifies the length in bits of the field
      of interest in the packet.

   Start Value

      If the R flag is unset the variable length Start Value field
      identifies the value to be matched at the point identified by this
      Pointer. 
      If the R flag is set the variable length Start Value field
      identifies the first value of the range to be matched at the point
      identified by this Pointer. 
      The length in bits of the Start Value field is as indicated by the
      value Length field.

   End Value

      The variable length End Value field is only present if the R flag
      is set and identifies the last value of the range to be matched at
      the point identified by this Pointer. 
      The length in bits of the End Value field is as indicated by the
      value Length field.

--julien

> >      Trænger du til at se det store billede? Kelkoo giver dig
> > gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

-- 
--julien

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 6 May 2009 16:23:49 +0100

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

On Wed, May 6, 2009 at 4:10 PM, Julien Laganier
<[email-masked]> wrote:
>> > The DSfield is fine. Â But for the ECN, using the general offset
>> > Â  Â  Â TrÃŠnger du til at se det store billede? Kelkoo giver dig
>> > gode tilbud pÃ¥ LCD TV! Se her http://dk.yahoo.com/r/pat/lcd
>>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 7 May 2009 14:52:42 +0200

> 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.
>

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:

      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
                     |           Offset              |    Pattern    |

                             Figure 2b: Bit pattern Pointer

Thoughts?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 7 May 2009 16:15:38 +0200

On Thursday 07 May 2009, Julien Laganier wrote:
> > 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.
> >
> 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.
>

Of course I messed up the second one for bit mattern, see an update 
below.

      0                   1                   2                   3

      0                   1                   2                   3
                     |           Offset              |    Mask       |
     |   Value       |
     +-+-+-+-+-+-+-+-+

--julien