Subject: revised guaranteed draft in following message

From: Craig Partridge <[email-masked]>
Date: Mon, 07 Aug 95 17:19:47 -0700

Hi folks:

I'll be sending out the lastest draft of the guaranteed service document
(with the changes made in Stockholm) in a message following this one.
I'm soliciting comment directly from the WG with this document before
issuing the new ID.

So far as I know, there are only two lingering problems in the document:

    * Getting a few of the details of IEEE floating point right (Thanks
    to JJ for his notes today. I've tried to incorporate his work in
    this draft)

    * Making sure we are comfortable with the min packet size parameter.

The min packet size parameter is a more complex problem.  There have been
some notes among the co-chairs and I've also gotten comments from several
folks that raised various issues.

One issue is that if one of our services uses a min packet size parameter in
its TSpec, the other services (in this case, controlled delay and predictive)
should also use that parameter in their TSpecs to allow us to do replacement
of services.

Another issue is whether the min packet size is the right parameter.  This
issue is very difficult, and the rest of this note is *my personal opinions.*

If you read the guaranteed draft, you see that we use min packet size
to compute a max packet rate (i.e., we divide r+b by min packet size
and say that's our max packet rate).  This begs the question of why we don't
ask applications to state their max rate directly.

Well, one good reason to use min packet size instead of max packet rate
is that we're worried about IP fragmentation.  In that case, if we hit
a link where the link MTU is less than the min packet size, we can reduce
the min packet size in the TSpec (thus increasing the rate).  HOWEVER,
note this isn't quite right.  Suppose our link MTU is R, the min packet
size is 2R but most packets are size 2.5R.  We'll reduce our min packet size
in the TSpec to R, when in fact it should be 0.5R.  This has two nasty
results: first, we'll give out the wrong min packet size (so one can't police
on packet size), and second we'll underestimate the max packet rate (worse!).
[To see the latter, suppose our r+b was 1000R: 1000R/2R = 500 pkts/sec.
1000R/2.5R is 400 pkts/sec.  Our estimated max rate with MTU of R is
1000 pkts/sec, but if we actually sent 400 pkts of 2.5R (our peak
rate at 2.5R), they'd be split into 3 fragments, giving a max rate of
1200 pkts/sec, which is more than our estimate].

Note too that by using the min packet size to compute the max packet rate, we
are probably wildly overcomputing the actual max packet rate in most cases.
(I.e. we're losing all 'round).

What if we just asked applications for their max packet rate directly?
Fragmentation is still a serious issue.  Suppose we hit a link with
MTU R and we computed our max packet rate based on the notion that we'd
send at that rate using packets of size 3R.  The hop where the MTU is
R needs to know (somehow) to triple our max packet rate.  But there's
no information the rate that tells it how to multiply the rate!  We'd
have to feed the hop the usual packet size (or some such) to even have
a hope of computing the right rate.  And that's not going to give a
perfect answer -- suppose our usual packet size is between 2.7R and 3.3R
where R is the min MTU of some link.  Then our multiplier is between 3
and 4.  If we picked a single number, we might pick the wrong one (say
2.9R) and cause the rate to be miscomputed.  But to figure out the right
recomputation factor, we'd need to advertise a range of packet
sizes and have the hops in the middle figure out what value in the range
gives them worst case fragmentation (yuck).

So we are caught in a bit of a muddle.

    * min pkt size does not work at all if there is fragmentation (yuck).

    * max pkt rate does not work if there is fragmentation unless we
    provide large amounts of information about packet distributions and
    assume lots of smart software (yuck).

If there is no fragmentation, we can probably use either min packet size
or max packet rate (haven't fully thought this through) and probably would
use rate (as the more direct parameter).

However, ensuring that no fragmentation occurs is hard.  Currently, MTU
discovery depends on routers sending back ICMP messages.  We don't want
to do that for a multicast stream of packets (we'll blow away the sender
if a path changes to one with a new MTU).  The only way I can think of
solving this nicely is to have the setup protocol (e.g., RSVP) do a form
of MTU discovery by checking the MTUs while path messages are being sent,
and feeding back the multicast path MTU to the sender (OPWA becomes 2PWA).
Note this also means that *senders* have adapt too (namely adapt their
packet sizes).  Heretofore, we've not talked about adaptive *senders*,
just adaptive receivers.

Alternatively, senders could always restrict themselves to packets no
more than 576 bytes long.... :-(

Better ideas (or better thinking -- I've found it hard to wrap my head
around this problem) are most welcome.

Craig

---

From: [email-masked] (Dilip Kandlur)
Date: Tue, 08 Aug 95 18:09:03 -0500

Craig,

it seems to me that what we are actually looking for is the maximum
number of packets/second that a router will see.  This parameter is
required to account for packet handling overheads which are not
reflected in r and b.

Let us start with a model in which the application provides a
parameter P, the max. number of packets/second.  Now, given r and b,
we can conclude that the packet size is [(r+b)/P].  If this packet
size is larger than the link MTU, R, we increase the packet rate to
account for the fragmentation to R * ceil((r+b)/(P*R)).  This
increased packet rate is now propagated to the next link.  (This is
probably appropriate since IP fragments are typically not reassembled
link-by-link.)

This leaves open the question of how a sender can determine the
maximum number of packets/second.  One possibility here is for the
sender to assume that the network can handle large packets (e.g. using
IP fragmentation) and choose an application-based packet size.  A
better option, as you suggested, is to have the sender adapt to an MTU
that is discovered.  The advertising mechanism of RSVP can easily
carry MTU discovery information using two passes.

Comments?

-- Dilip.