[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Diffserv] EF RFC and loss



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:albert.e.manfredi@boeing.com]
Sent: Monday, November 15, 1999 10:34 AM
To: Panos GEVROS
Cc: diffserv@ietf.org
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
manfredi@arl.bna.boeing.com


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

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