Subject: Mod: TOS bit semantics

From: Paul Ferguson <[email-masked]>
Date: Sat, 08 Nov 1997 00:40:50 -0500

After a few exchanges of e-mail on the side, I've been
persuaded to modify the delay indication bit semantics
expressed in:

 draft-ferguson-delay-drop-00.txt

from using the entirety of the 4 bit TOS field, to
instead using the lower order two bits to convey the
same indication -- in adherence to minimal encoding
principles.

The draft, as it stands at the moment, indicates that:

    Bit         Existing                Delay
   Value        Semantics               Indication

   1000   --   minimize delay           Highest delay sensitivity
   0100   --   maximize throughput        .
   0010   --   maximize reliability       .
   0001   --   minimize monetary cost   Lowest delay sensitivity
   0000   --   normal service           No delay sensitivity

The new & improved revision will indicate:

   Bit            Delay
  Value           Indication

   __11           Highest delay sensitivity
   __10             .
   __01           Lowest delay sensitivity
   __00           No delay sensitivity

This reserves the high order two bits for other
purposes. This will be included in *-01.txt (which
ironic, given that *-00.txt hasn't even been posted
yet).

That is, if I don't modify it again. ;-)

- paul

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Nov 1997 10:53:22 +0200

Bit         Existing                Delay

      Bit            Delay
     Value           Indication

i'm not sure if the new version is better than the old one in case
someone uses the tos field in its original rfc791/rfc1349 form, since
now the value 1000 doesn't anymore mean high delay sensitivity, but
becomes quite opposite as no delay sensitivity.

if we have an open playing field, i.e. if we don't have to care about
rfc791/1349, then of course the above makes sense.  does anyone know
what our mandate is?  are we allowed to suggests to iesg (or whoever the
ietf bosses are) that we want to totally junk rfc791/1349 version of the
tos field?

we also could get four levels of delay sensitivity without breaking
anything by taking the last (7th) bit of the tos octet in use that is
currently marked as "reserved":

bit 3 ... bit 7
    0         0		no delay sensitivity
    0         1		lowest delay sensitivity
    1         0         .
    1         1         highest delay sensitivity

but as i said in above, the right choice depends on our mandate.

-- juha

---

From: Paul Ferguson <[email-masked]>
Date: Sat, 08 Nov 1997 09:06:33 -0500

At 10:53 AM 11/8/97 +0200, Juha Heinanen wrote:

[paul]

>      __00           No delay sensitivity

[juha]

>ietf bosses are) that we want to totally junk rfc791/1349 version of the

Well, that's a good question. It appears that we have a couple of
choices here:

 1. Use the existing defined bit values in RFC1349 & the entire
    4 bit TOS field, just change the semantics,
 2. Use the low order two bits in the TOS field, and opt for
    minimal encoding,
 3. Use the low order 1 bit, as Juha proposes below, and the
    reserved bit, to achieve effectively the same thing.

I agree that this very much depends on the consensus that
we can effectively change the way with which we view RFC1349,
or effectively deprecate it. No one has effectively used the
existing semantics to date, so I don't foresee a major roadblock
here, but of course, I'd like to hear from others on this.

I tend to prefer 1 or 2, depending on whether minimal encoding
is actually important in representing 4 levels -- I still believe
that only 2 values (1 bit) is not enough. By the same token, I
tend to not want to use fields designated as 'reserved' unless
presented with no further options. In other words, I would try
to look for feasible alternative encodings before using the
reserved field.

- paul

---

From: Tony Li <[email-masked]>
Date: 08 Nov 1997 12:34:21 -0800

> ietf bosses are) that we want to totally junk rfc791/1349 version of the

I didn't realize we needed a mandate.  I could have sworn that this was the
IETF and that we were trying to fix a problem.  If we do have a mandate,
it's "running code and rough consensus".  Let's get on with it.

As far as the pragmatic issue of not breaking the deployed base, I'm
unaware of anything significant that would break by doing this.  In fact,
the only thing that I can think of that would break is in a back little
corner of IOS where you can create an access list to filter on those TOS
bits.  And that refers to the bits by name, so any change to the TOS field
breaks that.  I'm unaware of anyone actually using this feature.

Tony