Subject: Re: Proposed Fix to Fred's Problem

From: [email-masked]
Date: Sat, 23 Dec 95 12:31:50 EST

*** Resending note of 12/23/95 01:34                                           
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -                 
 From:                                                                         
 Subject:                                                                      
Subject: Re: Proposed Fix to Fred's Problem                                    
Lixia, thank you for your reply. I thought it would have discussed             
before, I appreciate the simplicity issues, and will not comment               
further. However, the throughput issue you raised is contradictory             
to my understanding so I commented there some. Best regards, Raif              
                                                                               
>Some of the reasons for not taking the approach                               
>- the foremost one: simplicity                                                
Simpler the better. I agree.                                                   
>- make smallest changes possible just to fix the problem                      
surely the right way to go, as long as the problem is fixed.                   
>- not all applications can adjust their throughput as a continuous            
>  variable.  therefore even if one's willing to pay the cost, the gain        
>  is unclear.                                                                 
I might be miles a way from the reality here and apologise                     
for your time if that is the case.                                             
Based on my understanding, guaranteed service guarantees delay.                
Given everything else being the same (i.e. Ctot and Dtot and b)                
larger R means smaller delay and smaller R means larger delay.                 
R is used to request a delay value and this                                    
delay is used to size the playout buffers, etc. at the                         
end stations and that is where its significance lies.                          
Different R does not mean different throughput to the application.             
R in turn is used in WFQ based on the flow model to be able to                 
deliver this delay (worst case). The use of WFQ and its variants               
however does not mean the application throughput is R.                         
Of course you folks know better, after all you put this framework              
together but this is what I understand by reading the spec.                    
                                                                               
As far as the application itself is concerned,                                 
the only application that I know that can change its                           
throughput is video coding. For example, I can not have a voice                
conference in which I will say.. let me hear one every five words              
since my host does not support the full throughput. The practicality           
of changing application throughput                                             
in the case of video encoding, on the other hand, at the best is               
questionable. Is the routers be knowledgable enough to discard                 
B frames of an MPEG video stream and send only the I frames.                   
Are we going to ask video servers to process each one of their                 
frames before passing to the IP layer to assign different ids                  
based on the importance of their contents. How about doing it                  
in real time for video conferencing?                                           
At any rate, if R is used as an indicator for delay, this discussion           
is immaterial and a router should be able to choose between the                
smallest delay (largest R) and the largest delay (smallest R).                 
I agree with you nevertheless that it introduces some complexity to            
the routers (i.e., your first two arguments). I can not judge how              
significant that is.                                                           
>We support functionalities requested by real applications, not the            
>otherway around as ATM tends to do.                                           
I will not go into this discussion. This is a more political                   
and/or philosophical issue than a technical one and will not                   
not help resolving the issue at hand. In another context, perhaps              
I would have tons to say.

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 23 Dec 1995 17:14:57 PST

For those who wondered what all this is about: Raif moved an exchange
from RSVP list to here.

> for your time if that is the case.                                             
If by "reality" you mean what is on the net *now*, or what may be there
6 months from now, then I'm afraid that the following paragraph is not
very relevant.

> delay is used to size the playout buffers, etc.  .....

> together but this is what I understand by reading the spec.                    
Your understanding sounds right to me.
But I do not see how this may contradict my statement.  You're saying
that applications using Guaranteed service may be able to benefit, and
I said that not *all* applications can adjust their throughput
continuously.  I think we are in agreement.
I consider the gain  unclear because we dont know how much of the
traffic will be using G-service.
Personally I believe it is the controlled load traffic that will take
of first and become the dominant realtime service.

> throughput is video coding.

Again, we do seem to agree a lot :)
But I should point out there have been recent work on audio encoding
that can also adjust the rate (e.g. to adjust the redundancy ratio to
be more loss-tolerant)

> in real time for video conferencing?

No problem.
There have been proposals of using multiple multcast groups for
layer-encoded video streams.  I believe active work is going on at
LBL.

> ......

talk to the router vendors.

> not help resolving the issue at hand.

I was not talking any politics.  I was stating our/my objective.

Thanks for the comments!

Lixia