Subject: "minimal subset" flow specification needed

From: [email-masked]
Date: Mon, 28 Nov 1994 11:11:23 -0800

(I keep forgetting that darned hyphen)
Bob

----- Begin Included Message -----

---

From: [email-masked]
Date: Mon, 28 Nov 1994 14:37:59 -0800

Fred,

There is also some question in my mind about the representation (syntax)
for a flowspec.  Craig's flowspec used a 2-byte floating point
representation for each number, while the CSZ flowspec uses a fullword
integer format.  Neither has tags to allow variable selection and/or
order of fields in a flowspec.

Craig's argument for the floating point representation is that we need
compactness and range, but not precision.  I like that argument.  I was
thinking of proposing a slightly different format, essentially the
high-order 2 bytes of an IEEE floating point number.  This gives 7 bits
of precision.  Size of a flowspec could become a real issue, I believe,
and 2-byte floating pont values look a lot better to me than 4 byte
integers.

The idea of a tag seems useful for extendability, but maybe it is not
necessary since there will be an overall type/version for the flowspec.
Tags also avoid a combinatoric explosion if it turns out
that we need different subsets of the possible parameters in different
flowspecs.  Since they allow you to omit fields you don't need, tags may
(or may not) cause a net reduction in size.

Bob

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 29 Nov 94 00:34:03 -0500

From: [email-masked]

    Size of a flowspec could become a real issue, I believe, and 2-byte
    floating pont values look a lot better to me than 4 byte integers.

What's your thinking here? (It's not obvious to me, but I assume there's
something I'm missing.) I'd assume there'd generally only be one, or a small
number, per RSVP packet, so the overhead there shouldn't be too bad. Is the
issue one of space in the router to store them?

	Noel

---

From: [email-masked]
Date: Tue, 29 Nov 1994 07:51:50 -0800

*> From [email-masked] Mon Nov 28 21:43:22 1994
  *> Date: Tue, 29 Nov 94 00:34:03 -0500
  *> From: [email-masked] (Noel Chiappa)
  *> To: [email-masked], [email-masked]
  *> Subject: Re: "minimal subset" flow specification needed
  *> Cc: [email-masked]
  *> Content-Length: 451
  *> X-Lines: 11
  *> 
  *>     From: [email-masked]
  *> 
  *>     Size of a flowspec could become a real issue, I believe, and 2-byte
  *>     floating pont values look a lot better to me than 4 byte integers.
  *> 
  *> What's your thinking here? (It's not obvious to me, but I assume there's
  *> something I'm missing.) I'd assume there'd generally only be one, or a small
  *> number, per RSVP packet, so the overhead there shouldn't be too bad. Is the
  *> issue one of space in the router to store them?
  *> 
  *> 	Noel
  *> 

Noel,

Sigh.  Maybe we should just merge the int-serv and rsvp mailing
lists...!  This question is strictly an RSVP protocol issue. [The
good news is that both lists are on one site, so at least we
suppress duplicates.]

Suppose you are holding a video teleconference with N others.  In the
simplest model, you have N video clips on your screen simultaneously,
so your video program will be making a Fixed Filter or Dynamic Filter
reservation which results in sending a Resv message containing N
(filterspec, flowspec) pairs.  Since each of the N others is also a
source, each will be sending Path messages towards you, and at some
point onward RSVP will want to merge all N flowspecs describing the
traffic sources (Scott Shenker's Tspecs) into a single Path message.

I won't go through the calculations here, but there will almost
certainly be some N values for which, given MTU's ~ 1KB, it will be
tight fit or worse (worse means semantic fragmentation is necessary).

I should also note that adding real authentication probably means
encryption keys or worse, which may turn out to dominate the problem.

Bob