Subject: Re: Don't let Delay eat up all TOS bits.

From: [email-masked] (Konstantinos Dovrolis)
Date: Wed, 19 Nov 1997 12:27:23 -0600

Hyogon,

>  I haven't seen ANY technical reasoning why we need more than 1
> delay priority bit in soft-guarantee Diff-Serv when hard-guarantee 
> Int-Serv failed to come up with even 3 different "feels" of delay
> guarantees (see earlier posting by Dave Clark). 

I kind of disagree with the first part of your statement. The recent
posting by Ed Ellesson on the successful and necessary use of four
delay preference classes in SNA networks seems to me that is a convincing
and technical argument that is based on working experience with
real networks, applications, and traffic. Would the results of a
simulation or of an analytical paper be more convincing to you?

Regarding what Dave Clark said earlier on the 3 different "feels"
of delay, I am sorry, but I would prefer to see some numbers. Were
they simulation-based results? If yes, for what kind of network traffic-load
are we talking about? A dozen of TCP connections or several thousands of
flows in a backbone/NAP router? Obviously, you will not get much delay "feel"
difference if there is no persistent queuing in the router. Also
what type of scheduling mechanism did they use? Is there any paper/TR
that presents their methods and results? The fact that something has been
said by a person that everybody in this field  respects in the
maximum degree does not mean that it is necessary always true :-)

Constantinos

---

From: [email-masked] (Hyogon Kim)
Date: Wed, 19 Nov 1997 22:56:29 -0500 (EST)

Constantinos,

>simulation or of an analytical paper be more convincing to you?

thanks for reminding me of his posting. Yes, it might be a 'successful'
example for use of multiple levels of priorities. But I wonder how much
successful example is that for Diff-Serv Internet? (Frankly I am not as old
a guy as to know SNA well enough to argue anything for or against it ;-)
Maybe Mr. Ed Ellesson could tell us how big was his SNA network in terms
of the diameter (propagation delay, number of hops, etc.), 
number of customers, how scalable is the method to distribute bandwidth
to priorities, what was the difference in delays between priorities that 
so predictably set priorities apart? From a sketchy reading, I couldn't see 
any numbers there which apparently convinced you to believe that
that example's plausible enough to work in Internet as well.

In fact, you bring up an important issue here. Are we talking about
_relative ordering_ of delay priorities or _definite numbers_ attached to
the priorities? (i.e. it's about the semantics of the delay bits)
I doubt you are talking about definite numbers, like 1ms for priority
1 and 10ms for priority 2, etc, considering for instance varying propagation
delays. If we are talking about the relative ordering, and we are selling 
some delay profiles to customers, you think you can sell more than
2 delay priorities in the Internet? How do the customers know you are
not cheating when the "feels" between delay priorities are not set apart
far enough? Relative ordering says nothing about the quantity of the gap,
does it? And that's where the "feel" factor comes in, and I am not 
as much convinced as you that you can create more than 2 "feel"s in the
soft-guarantee Diff-Serv Internet. I wonder how you can convince a 
subscriber of the worthiness of the 0.1ms difference his additional $5 
has made (although the bigger problem is not the possibly small values of
difference but it's the _unpredictability_ in the value from subscribers'
point of view), when Joe Schmo in the neighbor who bought higher delay 
profile just doesn't notice that huge difference in delay.

>flows in a backbone/NAP router? 

I really hate to quote many times what other people said without consent, but 
with appropriate apologies, 

:I don't think that we can construct more than about two levels of 
:best effort service that have a significantly different
:"feel". We went through the same exercise with real time. Initially, we
:proposed to have three levels of real time service, that would be
:distinguished by the "feel" of the delay. The delays had to be
:substantially different, to make the distinction worth having, and after
:we screwed around with a range of offered loads and queue service
:disciplines, we finally realized that if we forced the three levels of 
:delay far enough apart so that they really seemed different, the bottom 
:two were worse than best effort. So we bagged the whole idea, and just 
:went for the very simple, single level "controlled load". I suspect that 
:the same will prove true for best effort service as well -- I doubt that 
:you can pull the traffic apart into more than two queues, and still end up 
:with queues that actually have much of a difference in the serice they provide.

My understanding was that he was summarizing the experience of the
_Int-Serv group as a whole_. I was not following up Int-Serv activities
until lately, so please correct me, Int-Serv gurus, if I am misinterpreting 
something here. Actually, I will be grateful if some of you could
answer Constantinos's questions since I also wonder what exactly
baffled you.

>Obviously, you will not get much delay "feel"

Exactly, plus varying propagation delays. Not many feels, definitely. 
This was my point.

>The fact that something has been

You got me there, Constantinos, chalk one up for you. I guess the good
old days of free-riding on giants' shoulders is over for me. ;-)

>Constantinos

-- Hyogon
------------------------------------------------------------------------------
Hyogon Kim ([email-masked])	       		       |        (201) 829-4728
Research Scientist				       |           MCC 1B-225B
Internet Architecture Research Laboratory	       |      445 South Street 
Bell Communications Research			       |  Morristown, NJ 07960
------------------------------------------------------------------------------