Subject: Re: invalid values for intserv parameters?

From: [email-masked]
Date: Wed, 2 Apr 97 15:12:55 PST

*> 
  *>    The ISI implementation sets the defaults:
  *>    
  *>    	p = floating pt infinity
  *>    	m = 0
  *>    	M = 65535
  *>    
  *>    in a Tspec.  These values seems sensible to me.
  *>    
  *> p seems fine, but let's look at the other two.
  *> 
  *> m says "I'm going to send zero-length packets"   ???
  *> 

JJ,

It is my turn to say that I am probably misunderstanding, but it seems
to me that 0 is a sensible default for m.  The definition of a minimum
policed unit X is:

	if (pktlen < X) then use X instead of pktlen for policing.

If I set X to zero, I am nullifying this rule; i.e., I am saying there
is no per-packet overhead to be considered in the traffic control
decision [which may get an application in trouble if it has figured
things exactly, but that is its problem for not specifying m].

What do you think the default m should be?  23?  137?  1234?

  *> 
  *> With M of 65535, you will not successfully install a reservation over
  *> any link with an MTU of lesser value.
  *> 

That seems like a good point.  You think the default should be zero?

Bob

---

From: John Krawczyk <[email-masked]>
Date: Wed, 2 Apr 1997 18:40:08 -0500

On Wed, 2 April, [email-masked] ([email-masked]) wrote:

   JJ,

   

As usual in the IETF process, the documentation doesn't cover the entire
story that lead to the creation of the parameter.  I recall asking quite
a few intserv meetings ago how one figures out exactly how much
bandwidth to reserve for a flow when the "r" parameter doesn't take the
link-level headers into account.  The "m" parameter was created so that
you could calculate that you need one link-level header per "m" bytes,
in the worst case.  If the sender then sends packets less than "m", it
gets penalized in the policing.

If we allow 0 for "m", what does that mean?  Should I assume just an IP
and UDP header?  That means, on ethernet, I'm going to say "I need 14
bytes of link level for every 28 bytes of data".  In other words, I have
to inflate your reservation by 50% to ensure that, if you are bad, you
don't cause major problems for me.

As far as what to set it to, rsvp-use-01 says:

   The minimum policed unit parameter [m] should generally be set equal
   to the size of the smallest packet generated by the application. Note
   that smaller values of this parameter may lead to increased
   likelyhood of admission control failure when a receiver tries to make
   a reservation. In some cases, an application transmitting a small
   percentage of very small packets may therefore choose to set the
   value of [m] larger than the actual minimum transmitted packet size.
   This will increase the likelyhood of the reservation succeeding, at
   the expense of policing packets of size less than [m] as if they were
   of size [m].

I don't think you can have a "default".  It has to match the
characteristics of the application.  I don't think zero can be used,
ever.

     *> 

I think we need some agreement as to what this means, as Fred has
indicated a interpretation different from mine:

    If the value there exceeds my MTU, I do not forward the PATH message on
    the link. I assume that Path MTU will come along and do the right thing.
    A zero value, to me, indicates that the guy wants his messages to go
    through no matter what, and will either accept fragmentation and its
    implications, or will do PATH MTU to recover. I'd suggest the latter
    anyway, as the route may change and something might go awry when it
    does.

My interpretation was that M in the PATH was sent unchanged, and when a
RESV was received, you needed to check M to ensure that the packets
would fit.  If Fred's interpretation is what everyone else thought,
that's fine - but let's write it down.  Also, if zero means, "I don't
care, go ahead and fragment!", let's write that down too.

Similarly, Fred's interpretation of what a router does with "p" is
different from mine:

    I treat it as zero; if you tell me that your peak rate is zero, I will
    not increase it to reflect the speed of a link. However, if you tell me
    it's infinite, I will reduce it to the speed of the link, as the fellow
    beyond me who receives the data will not receive it any faster than I
    can send it to him.

Again, I thought that "p" was left untouched in PATHs.  Should a router
modify this parameter?  Let's write it down (I sound like a broken
record).

I'd like to hear what JTW thinks about all this....

-jj

---

From: Craig Partridge <[email-masked]>
Date: Wed, 02 Apr 97 17:01:38 -0800

JJ,

       

Right, and it says just this on page 15 of the guaranteed draft.  Setting
m to zero effectively means you need to assume an infinite packet header
overhead.

Craig

---

From: Greg Troxel <[email-masked]>
Date: 03 Apr 1997 08:12:54 -0500

I believe that values of 0 and 1 for m are equivalent, since a packet
of size zero is not meaningful.

Further, since this is IP, a value smaller than 20 is probably not
meaningful.  So perhaps an implementation would treat all values of m
<= 20 as being 20, since packets < 20 are not proper IP packets and
will not be forwarded.

(If some sort of header compression is involved, this may not be true.
I haven't been paying attention to how int-serv and header compression
interact.)

Thus, if there are 14 bytes of link-layer overhead, and a request
comes in with m 0, one could 

 treat it as 1, using the first assumption, and reserve ((14+1)/1) *r

 treat it as 20, using the IP-packet assumption, and reserve
  ((14+20)/20) * r

This does indeed impose an admission control penalty on reservations
with a small m, but this is reasonable and properly reflects the
resources that must be allocated to deliver the service.

Does an effective floor of 20 for m make this situation less
problematic?

        Greg Troxel <[email-masked]>