Subject: status of predictive service

From: Craig Partridge <[email-masked]>
Date: Tue, 27 Jun 95 16:20:01 -0700

Hi folks:

I got a couple of queries about the status of predictive service.  So let
me try to briefly answer that and I'm sure my co-chairs will jump in
with details or corrections.

We (meaning those of us who have been editing the documents) have not made
as much progress with predictive service as with controlled delay and
guaranteed for two reasons.  First, we had a shortage of time.  Second,
predictive is arguably the most difficult service to properly charactertize.
Rather than rush, we decided to aim for getting predictive service
considered for Proposed Standard at the fall IETF -- this meant we didn't
need to kill ourselves to get an Internet-Draft out in June.

We have a few volunteers to actually take on revising the predictive
service draft (which is great!) and I think will lead to much quicker
progress.

Craig

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 30 Jun 95 13:53:19 +0100

in draft-ietf-intserv-control-del-svc-01.txt
it says "It is expected that if an element offers
both predictive service and controlled delay service, that it need
not implement both but can use the predictive service as a
controlled delay service."

as a firm believer in the predictive service, i have failed to
convince myself that this statement is true i nthe context of a path
made out of multiple providers - surely the game they will play will
be to pass the buck for meeting a delay budget so that they canb admit
more calls and get more revenue, but wil lthen find that the last hop
(or somewhere along the way) rejects the RSVP setup as not meeting the
spec....

can someone convince me i'm wrong...

 jon

---

From: Craig Partridge <[email-masked]>
Date: Fri, 30 Jun 95 15:46:16 -0700

John:

    It isn't clear to me what your concern is here (and pardon me if
I'm dense).

    The statement in the controlled delay document is simply pointing out
that predictive service gives a better service (more stable delays with
similar loss guarantees) than does controlled delay.  So if a controlled
delay request reaches a device or network that only does predictive
service, it can accept the request by giving that flow predictive service
instead.

    Is your concern that in a multiprovider environment, providers will
have an incentive not to do this?  If so, why?

Craig

---

From: Craig Partridge <[email-masked]>
Date: Fri, 30 Jun 95 15:46:16 -0700

John:

Craig

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 02 Jul 95 15:49:27 +0100

Craig

my concern is that some services may not be offered since the game a
provider can play with charges and percentages of different service 
they provide may lead them to always downgrade....but i havnt thought
it through...sorry...

 jon