Subject: Re: time constants

From: Christian Huitema <[email-masked]>
Date: Thu, 26 May 1994 19:35:35 +0200

John,

I dont like crackles any more than you do. We differ on how to avoid them. The
ball is clearly in my camp here: up to now, the one proven method to avoid
crackles is bandwidth reservation, which is why you set out to implement
reservations. I dont like the consequences of implementing reservations, thus
believe that we should try an end to end solution. But you are absolutely
right to mention that whatever has been done yet in that domain looks like "a
toy" and that the charge of the proof is on me!

Christian Huitema

----- End Included Message -----

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

---

From: John Wroclawski <[email-masked]>
Date: Thu, 26 May 1994 14:00:03 -0400

From: Christian Huitema <[email-masked]>

   John,

   I dont like crackles any more than you do. We differ on how to avoid
   them. The ball is clearly in my camp here: up to now, the one proven
   method to avoid crackles is bandwidth reservation, which is why you
   set out to implement reservations. I dont like the consequences of
   implementing reservations, thus believe that we should try an end to
   end solution. But you are absolutely right to mention that whatever
   has been done yet in that domain looks like "a toy" and that the
   charge of the proof is on me!

   Christian Huitema

Fair enough, but be careful. I'm not trying to defend the "hard
reservation" camp. Rather, I see reservations essentially as a
backstop mechanism for the end-to-end approach, to ensure that one can
bound the quality of service when one needs to. In my preferred model,
reservations are used only when required by the user, not just
"because it's video" or whatever. 

This is of course tightly tied to the question of billing. The
conventional wisdom demands usage-based billing, which I reject on a
number of grounds. In that situation, optional user-controlled
reservations provide an excellent way out - if the non-reserved
service is OK, you don't pay extra; else push the button and pay a
little more. Note that this model provides an excellent economic
incentive to develop and market better adaptive applications.

		-john

----- End Included Message -----

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 May 1994 14:15:57 +0200

> I hate to disagree with the chair of the Architecture Board :-)...

Oh, really? I thought instant consent was a prerogative of the position!

I may have a particular bias here as I do not believe that we need
reservations in the general case, certainly not the kind of "meet or die"
reservations that John is alluding to. I believe that the normal Internet
application should be adaptative, i.e. should continue to work in a downgraded
mode if the reservation is not met. But I reckon that we don't have much
experience with adaptative applications...

Christian Huitema

----- End Included Message -----

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

---

From: John Wroclawski <[email-masked]>
Date: Thu, 26 May 1994 13:22:51 -0400

I may have a particular bias here as I do not believe that we need
   reservations in the general case, certainly not the kind of "meet or die"
   reservations that John is alluding to. I believe that the normal Internet
   application should be adaptative, i.e. should continue to work in a
   downgraded mode if the reservation is not met. 

It sounds like you might be confusing two somewhat different ideas:

I'm quite in favor of adaptive applications when appropriate, which I think
is most of the time. These applications can adapt to a wide range of
provided service, within limits. 

The job of the reservation, in this case, is to ensure that the
network service stay within these (perhaps somewhat loose) limits, to
allow the adaptation algorithm to work, and to bound the worst case
performace of the application.

I have absolutely no doubt that it is unacceptable for an application
to display undesired dropouts, service interruptions, etc. to the
user. These would happen as a consequence of the network service
degradation exceeding whatever limits were chosen by the application
(or application user, in the case of an app with a quality control
knob).

Cable TV does not drop out transmissions. Properly functioning
telephones do not allow more than a minimal amount of crackling, and
every crackle provides a market advantage for the other guys. If the
internet is to grow into universal communication infrastructure it has
to do at least as well. If it doesn't we are simply building a toy.

			-john

----- End Included Message -----