No subject

hurt the client's service in both assured and premium at all. I assume,
this is because of refinements of traffic conditioners used. My intention
of asking this question was "do we need such an (adaptive) protocol
complexity"? If not, then "do we need to have a different levels of
complexity in the protocols that can used for each service class"? /Or
"One uniform adaptive protocol will suffice cause traffic conditioners can
take care of this"? I assume all is a possibility. What would be a proper
trend to go? Thank you very much

Alper K. Demir


On Wed, 14 Mar 2001, Kathleen Nichols wrote:

> 
> Kedar Poduri carried out some simulations like this quite a while back
> when we were talking about something called a "virtual leased line"
> built from the EF PHB described in RFC2598. This is real easy to do
> (of course, you need a shaper at the edge, but Van's been saying that
> since the origins of this as his "premium" service). You can look at
> slide 23 of the talk at:
> http://www.nren.nasa.gov/CFP/nichols_pres/index.htm, a NASA NREN
> workshop on QoS. 
> 
> It's supposed to "look like a wire".
> 
> 	Kathie
> 
> demir wrote:
> > 
> > Hi,
> > There has been vast amount of research on how TCP will react on top of
> > services based on AF/AF-alike PHBs. However, I am not aware of a research
> > that elaborates TCP on top of EF/EF-alike PHBs from service perspective
> > (it seems this is unneccessary at all???). I am aware of that TCP is a
> > widely implemented and used protocol for congestion control and
> > avoidance. I assume, in a "short" time scale, TCP seems reasonable to be
> > used for AF PHB-based services cause TCP-friendly traffic conditioners
> > would refine the TCP's behavior. It seems to me that, may be, we need
> > different adaptive protocols for different service classes (TCP has been
> > developed for the "best-effort" service class). Any
> > ideas/insights/comments? I appreciate very much.
> > 
> > Alper K. Demir
>