Subject: Re: Throughput specifications

From: [email-masked] (Luca Lombardi)
Date: Tue, 28 May 1996 20:15:51 +0200

Forgive me for replying so late, we had a persistent technical problem with our Internet access. 

Message from [email-masked] 16-MAY-1996 23:48:49.77  :

>     I think that in such an environment 
>     there can be also a need for a service class which allows users to specify 
>    a QoSrequest about achieved throughput; i.e., a certain amount of data to be
>     transferred over a certain time interval.
> 
>     It seems to me that this doesn't map 
>     easily to a specification about the delay of single IP packets.
> 
> Actually it does.  For instance, the guaranteed specification says that
> someone emitting a stream of data (within the guaranteed QoS parameters)
> will, for any individual packet, see a delay of no more than X.
> 
> If you send 12 packets (and assuming they meet the advertised QoS), each
> will see a delay of no more than X.  So you can compute the overall delay
> by simply computing:
> 
>     (a) how long, according to the QoS rules, it will take to be allowed to
>     place the 12 packets into the network
> 
>     (b) the guaranteed delay X
> 
> and adding the two results.
> 
> Another, perhaps simpler, way to express this point is that delay and bandwidth
> (which is data over a time interval) are simply duals of each other.  Given
> a certain amount of data you want to send and a target value for either delay
> or bandwidth, you can compute the other value.
> 
> Craig

You're right, but I mean that a "throughput specification" does not necessarily imply a specification about the maximum delay of the single IP packets. If I 
want to send a number of datagrams in some amount of time, they haven't to be 
transmitted with the same delay, but I can tolerate that some packets are 
"faster", others are "slower". In some sense, I'm interested in having a certain"mean" delay over a "reasonable" time interval. What you say is really an easy 
way to map delay and bandwidth, but I think it is more suitable for untolerant 
delay-sensitive applications. FTP users, for example, usually have a (limited) 
tolerance about overall delays, but they have no playback point to set.

Best regards

Luca Lombardi

-------------------------------------------------------------------------
Coritel (Consortium of Research in Telecommunications)
c/o Facolta' di Medicina e Chirurgia
Universita' di Tor Vergata
Via di Tor Vergata 135
00133 Roma (Italy)
-------------------------------------------------------------------------

---

From: Mikael Degermark <[email-masked]>
Date: Thu, 30 May 1996 22:47:26 +0200

Hello Luca,

You might want to read Dave Clark's article
on a mechanism for service discrimination among
Best-Effort flows. This seems to be what
you ask for. Clark presented this at the LA IETF
meeting.

The article is called 

	Adding Service Discrimination to the Internet

and is available via the Internet, e.g., 

	http://ana-www.lcs.mit.edu/anaweb/ps-papers/TPRC2-0.ps
	http://ana-www.lcs.mit.edu/anaweb/pdf-papers/TPRC2-0.pdf
	
Micke Degermark