Subject: invalid values for intserv parameters?

From: John Krawczyk <[email-masked]>
Date: Wed, 2 Apr 1997 16:44:42 -0500

Hi,

First, I'll apologize for including both lists, but I think I'd miss
some people who might want to be involved in the discussion (this is
both an implementation issue and may require slight text change to an
int-serv spec).  If it means anything, I'm one of the people who will
get two copies... :)

Some implementations I've run across send and will accept values of zero
for the following intserv parameters in Tspecs (within a PATH or RESV
message):

  peak data rate (p)
  minimum policed unit (m)
  maximum packet size (M)

I don't think this is correct, and I think an implementation should
reject these values (we're guilty right now of accepting zero m and M
values).

Let's take these one at a time:

Peak data rate:  rsvp-use-01 says:

   The peak rate parameter [p]
   may be set to the sender's peak traffic generation rate (if known and
   controlled), the physical interface line rate (if known), or positive
   infinity (if no better value is available).  Positive infinity is
   represented as an IEEE single-precision floating-point number with an
   exponent of all ones (255) and a sign and mantissa of all zeros.

An implementation may accept a value of zero, but that value has no
meaning.  Since zero is currently undefined, I wouldn't mind if we
altered this text to let zero have the same semantics as infinity.

Minimum policed:  The reason this is present is so that the admission
control can take link-level headers into account.  Without it, there's
no way to do this.  rsvp-use-01 implies that this has to be set to a
non-zero packet size, but doesn't explicitly say so.

Maximum packet: This is necessary so that an implementation can reject
flows whose max packet size exceeds the MTU of the outgoing link.
Again, without this information, admission control can't do it's job.
rsvp-use-01 implies that this has to be set to a non-zero packet size,
but doesn't explicitly say so.

Comments?

-jj

---

From: Subramaniam Vincent <[email-masked]>
Date: Wed, 2 Apr 1997 15:03:17 -0800 (PST)

> non-zero packet size, but doesn't explicitly say so.

  (I do  not want to take this discussion off focus, but the m parameter
  is also there to let admission control make a worst case estimate of
  packet processing overhead. m limits the maximum arrival rate. If
  the token bucket was (r,b), in terms of bytes/sec, it is accounted for
  by the policing function as an (r/m,b/m) bucket, in terms of packets.)

  That being said, the minimum possible value for m would be something
  like (link layer hdr size + network layer header size + 1? byte of
  data). Using this, would result is the maximum possible estimate for
  processing cost for this flow. (the above sum will be a global constant
  per interface per layer 3 protocol)

  a. One way is to slap this maximum possible processing cost for
  a flow that has set m=0. Thats like a penalty, and implies flows
  should give valid values.

  b. Another way is to reject admission for the request level of service
  (too picky)

-vince

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Apr 1997 14:54:59 -0800

>altered this text to let zero have the same semantics as infinity.

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.

>non-zero packet size, but doesn't explicitly say so.

I think this should be allowed to be zero. Zero means "I do not enforce any
meaningful minimum size."

>but doesn't explicitly say so.

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.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"I don't want parole. I'm too busy working on my web site."
                       Charles Manson, 3-27-97 at his parole hearing.

---

From: John Wroclawski <[email-masked]>
Date: Thu, 3 Apr 1997 02:19:27 -0500

At 4:44 PM -0500 4/2/97, John Krawczyk wrote:
>for the following intserv parameters [...]

>Minimum policed:

Earlier msgs from you, Craig, and Vince pretty much covered this, and I'd
agree with:

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

However, an issue occurs to me. m is defined to include the IP/UDP/RTP/etc
header size, but not the link level header size. But I have just thought
about IPSEC. Can we always assume that an application will know when IPSEC
is being used, and how much additional IP-level header has been added to
use it?

(The only other simple alternative I can think of is to treat ipsec headers
as link-level rather than IP-level, so that each link seeing an
ipsec-wrapped flow adds some additional overhead amount to whatever its
real link-level overhead is. Presumably in some cases that additional
amount has to be an educated guess, since you can't see inside the packet).

>Maximum packet:

Need to mention intserv and RSVP separately...

From the perspective of the intserv service module at a router, M is the
largest packet size it is obligated to deal with once the flow is set up.
If a larger packet arrives, all bets are off. But if the packet is smaller
than M (and otherwise OK), the router has to give it the service.

Most/all routers will reject an admission request with an M larger than the
link MTU, because they can't deal with classifying or scheduling fragmented
pkts.

But this is not the only use. An application that is never going to send
pkts larger than 200 bytes would want to ask for an M -smaller- than the
link MTU. This may increase the app's chance of getting past admission
control -  because the router can use smaller buffers or schedule the link
more precisely with smaller packets or whatever.

So M is concerned with more than just link/path MTU.

Now, applying the rules above exactly, an M of zero means that the app is
saying that it does not care whether any pkt larger than zero gets the
special service. A great deal for the router, but probably not what you
wanted.

So I would say that from the intserv perspective the meaning of an M of
zero is quite well-defined, but useless, so the documents imply that you
shouldn't do it.

The max packet size computation scheme in draft-rsvp-use supports this.
Receivers learn the path MTU (actually, the largest pkt size a particular
-service- can support along a path, which is usually but not always the
same as the best-effort MTU) from ADSPECs, and so can avoid asking for
values of M that are too big and will fail. Senders describe the largest
pkts they'd like to -send- in the M parameter of a sender-tspec. At each
hop, RSVP requests a value of M equal to the smaller of (what the path &
receiver supports) and (what the sender wants to send); the value of M most
likely to be accepted by the intserv service. Finally, when the RESV
request gets to each sender, it can look to see what value of M is in place
along the path, and limit its packet size accordingly.

So senders, receivers, and path capabilities all get a say in the max pkt
size. If one of 'em asks for zero, the reservations along that path will
have an M of zero, which triggers the intserv meaning above.

So I would say that from the rsvp-use perspective the meaning of zero is
also both well-defined and to be avoided.

>Peak data rate:

From the intserv perspective, peak rate is peak rate; if you pick one and
then exceed it you may expect to get stomped on by elephants. So again a
peak rate of zero is, I'd say, both well-defined and not a good plan.

The current rsvp-use document does not "adjust" peak rates contained in
sender-tspecs. If both a sender and a receiver pick infinity, the rate
delivered to the intermediate nodes is infinity; it's not (in the spec)
adjusted down to the link speed. This was the topic of some discussion in
the past, which was inconclusive. The current behavior is the most (perhaps
"too") conservative, but it is safe for all.

>altered this text to let zero have the same semantics as infinity.

We could certainly do that if it was useful to people.

-john

---

From: John Krawczyk <[email-masked]>
Date: Mon, 14 Apr 1997 11:59:59 -0400

Hi,

I'd like to see if I can start to wrap up this discussion.  I think we
have an existance proof that the current state of the documents provides
too much room for interpretation and therefore some clarification on the
allowed values is necessary.

1) Minimum policed.

Some people agreed with my statement that there is no reasonable default
and zero should not be legal.  One suggestion equated zero with one,
which results in a worst-case estimation of link-level overhead and a
higher probability that the reservation will be rejected.  I would lean
toward making zero illegal, as this would force applications writers to
really think about this value (and make it useful).

2) Maximum packet.

As JTW put it, a zero value for M "is quite well-defined, but useless".
If it's useless, I'd just rather make it a non-option.  In any case, I'd
suggest taking the text from JTW's email and sticking it into the
rsvp-use document to explain this (despite his assertion that the
document already implies this).

3) Peak data rate:

Two issues here:

a) One implementation adjusts this parameter.  JTW asserts that this
should not be done.

b) Zero has no meaning according to the documents.  One suggestion is to
equate zero and infinity.  I have no problem with this, but I did
receive one comment that we may want to reserve this value.

-jj