Subject: RE: [Diffserv] EF RFC and loss

From: "Li, Renwei" <[email-masked]>
Date: Mon, 15 Nov 1999 13:07:23 -0800

I guess you have confused Panos' "no queuing delay"
with delay. 

When a packet is sent, the delay is 
the sum of a few finer delays: algorithmic delay (codecing),
architectural delay, transmission delay, queuing
delay, etc. 

I tend to agree with Panos to that EF is supposed to have
"zero queuing delay". But I am not very sure if the RFC
really means this. Zero queuing delay does not mean that
there will be no delay between two ends. Even the real 
leased lines still have a sort delay such as transmission 
delay, multiplexing delay, etc. The VLL just emulates such 
lines from the user's perspective. 

Comments?

Renwei

-----Original Message-----
From: Albert Manfredi [mailto:[email-masked]]
Sent: Monday, November 15, 1999 10:34 AM
To: Panos GEVROS
Cc: [email-masked]
Subject: RE: [Diffserv] EF RFC and loss

Panos GEVROS wrote:

> may i add that
> Wires also don't buffer packets

Well, even telephone systems are digital now, so even they suffer
from _some_ amount of packet delay. EF is supposed to emulate this
kind of service, as well as perhaps less stringent requirements.

> from previous discussion in this thread my understanding
> was that :
> 	-EF is about *no* loss and *no* queueing delay.
> 	-packets that arrive on different input interfaces
> and need to be forwarded
> on the same output interface EF queue may create
> instantaneous backlog and
> non-negligible queueing delays.

Uh, well, why not let's pick a packet size of, say, 53 bytes?
That'll keep delay low enough. :)

Everything I've read so far about interactive applications used by
human beings is that 150 msec is considered acceptable. This does
not necessarily apply to control systems, which may have much more
stringent requirements.

So EF if used for interactive multimedia applications does not need
to be _no_ delay. If used in a control system setting, delays in the
1 to 10 msec range or so are certainly within the realm of
possibility. But this would typically be over short distances/few
hops.

Bert
[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 15 Nov 1999 16:49:17 -0500

> lines from the user's perspective.

"Leased lines" these days are also services run over Frame Relay or
ATM. Both of which will incorporate buffering and queuing delays, as
well as propagation delay.

Zero queueing delay means that no packet shall be held back by
another packet at any of the hops. But if flows merge anywhere along
the path, you will have a statistical probability, even if the links
are over-provisioned, that queueing will occur. I don't see too much
you can do about this other than reserve paths, and then synchronize
your admission control such that merging packets will not be
admitted into the diffserv net simultaneously.

Does anyone have any other real-world options?

Bert

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 15 Nov 1999 14:44:45 -0800

"Li, Renwei" wrote:
...
> lines from the user's perspective.

In fact 2598 does not say "zero queueing delay". There should
be no average or standing queue in any EF buffer (falls out from
the definition). Your last statement is the accurate one, though
the "user's perspective" might be arguable. The thing to look
at is how do the transitory queueing delays experienced show up
to the endpoints which are expecting a VLL of some rate which
should be considerably smaller than the bandwidths of the
links the packets traverse. If you expect a VLL of 64 kbps and
get delayed behind 10 packets at 100 Mbps someplace in your
path, how does that appear at the endpoints? If this doesn't
work for you, do something else.

---

From: Siamack Ayandeh <[email-masked]>
Date: Thu, 18 Nov 1999 13:00:22 -0500

Kathleen Nichols wrote:

> the definition).

Kathie,

If it is not TDM, then the average "or standing" queue length and hence
delay would be greater than zero.

Regards, Siamack