Subject: [Ieprep] Preemption

From: "Beard, Cory" <[email-masked]>
Date: Mon, 18 Mar 2002 18:29:02 -0600

In the IP Telephony Framework draft, non-preemptive action is stated as a primary objective.
 
How does this translate to packet-level dropping policies in IP?  It seems to me that RED could be seen as a form of preemption.  Should we be on record as not supporting RED, or should a distinction be made between call-level preemption and packet-level preemption?
 
IMHO we just should take no position about preemption in the framework document.  It can be discussed as a possible implementation approach (depending on jurisdictional guidelines) but should not be stated as a primary objective in the framework document.
 
Cory Beard

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Keptin Komrade Dr. Bobwrench" <[email-masked]>
Date: Mon, 18 Mar 2002 17:08:29 -0800

The fact that any number of underlying protocols may be configured or
built in a preemptive manner should be addressed but not specified. We
cannot make any assumptions about the underlying protocols, any of which
may have any number of implementational effects.

Bob

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 19 Mar 2002 01:15:53 +0000

Cory,

> How does this translate to packet-level dropping policies in IP?  It
> seems to me that RED could be seen as a form of preemption.  Should we
> be on record as not supporting RED, or should a distinction be made
> between call-level preemption and packet-level preemption?
>
> IMHO we just should take no position about preemption in the framework
> document.  It can be discussed as a possible implementation approach
> (depending on jurisdictional guidelines) but should not be stated as a
> primary objective in the framework document.

hmmm, close, but I don't really subscribe to the notion that RED is
a form of preemption.

but instead of focusing on that debate, i think we can take a position
that at a minimum, we use non-preemption as a default goal for call
establishment.  so in a sense, it would apply to actions taken upon
call setup signaling via SIP, of H.323

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Mar 2002 19:46:12 -0600

>> In the IP Telephony Framework draft, non-preemptive action is stated

As there is ongoing work *with* preemption (MLPP and Assured Services) that has
been frequently brought up in discussions on this list, stating that *a*
default objective is "non-preemptive" is appropriate IMO.

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Sean Donelan <[email-masked]>
Date: Tue, 19 Mar 2002 00:15:11 -0500 (EST)

On Mon, 18 Mar 2002, Beard, Cory wrote:
> How does this translate to packet-level dropping policies in IP?
> It seems to me that RED could be seen as a form of preemption.  Should
> we be on record as not supporting RED, or should a distinction be made

I'm not sure if you are serious.

In an IP network, packet drops are a form of signalling.  The various
types of queue management (Tail-drop, WFQ, RED, WRED, etc) use packet
drops to signal senders how fast they can send data.  The quanitity of
different queuing disciplines demonstrates it is not a simple problem
for packet networks.

In a circuit-switched network you don't need feedback on how much
instantaneous bandwidth is available on a path once the call is
connected.  You either get a busy signal or a ringing signal.  Once
the call is connected, the capacity doesn't change until your call
ends, pre-empted or the path fails.

In a packet-switched network, the instantaneous bandwidth available may
increase or decrease during the session as the flow is re-routed or other
traffic passes through the same bottleneck.

Without packet drops, a sender would need some other method to track
of how much instaneous capacity is available along the entire path
and control its transmission rate so it doesn't overrun any buffer
anywhere along the path. Packet drops aren't the only method, but it
is the method used for many protocols built on top of IP.  IP Telephony
could develop its own bandwidth control protocol which doesn't use
packet drop signalling for congestion notification.  But it would
eventually still have to share the same network with other IP protocols
which do use packet drop.

How many phone calls can a T1 support?  23, 24, 48, 96, 200?  A circuit
switched network designer can give you a fixed answer.  A packet switched
network designer can only give you a probalistic answer.

I suspect you are stuck with packet drops assuming you want to use an
IP network.

---

From: Fred Baker <[email-masked]>
Date: Fri, 22 Mar 2002 14:29:58 -0600

>I suspect you are stuck with packet drops assuming you want to use an

if you are doing call control (SIP/H.323) in an IP network, you most 
definitely can manage call count.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 22 Mar 2002 15:19:01 -0600

> definitely can manage call count.

Although translating call count to bandwidth may be an approximation
(good for voice codecs as long as users don't cheat at call setup time,
iffy for video).

---

From: Fred Baker <[email-masked]>
Date: Sat, 23 Mar 2002 01:31:13 -0800

>(good for voice codecs as long as users don't cheat at call setup time,

you could always signal your bandwidth, using RSVP with the EF tag on it. 
We've done a fair bit of work to make that possible...

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 23 Mar 2002 10:18:26 -0600

Yes, I (mis)understood your earlier comment as implying that
application-layer signaling could substitute for network-layer
reservations. This (mis)understanding is unfortunately a rather common
notion; H.323, to name one, proposes this and it pops up periodically on
various SIP mailing lists. I believe we're in agreement.