Subject: Re: [Ieprep] updated requirements documents (telephony)

From: [email-masked]
Date: Thu, 12 Dec 2002 16:47:44 EST

I believe that the one "issue" in Section 4 needs to be described more fully.

1) The point in alternate routing for ETS is not that existing flows are 
automatically rerouted if a router becomes unavailable (even though this is 
useful to maintain a connection when a failure occurs). It is that, while the 
packets for a normal traffic might follow a specific, efficient path (to 
setup a new connection), the packets for an ETS call should attempt 
additional routes (even if very inefficient) which the normal call does not 
if there is congestion on the normal route. (Yes, I know all the arguments 
about "congestion can't happen in the core", but it's been clearly admitted 
that it can occur on some access links where alternate routing could also be 
used.)

The current second paragraph seems to limit the issue of "alternate routing" 
at the application layer to "choosing .. egress points to the PSTN". A 
significant issue for survivability and congestion handling in some networks 
could be the desire for abilities to alternate route around congestion within 
the IP portion. (The ability to reroute around failures is already assumed.)

I suggest this section on Alternate Paths be split into two separate 
sub-parts to address the two "layers" within IP and relate each to what the 
PSTN did (or couldn't do) as follows:

1) Alternate paths

Experience with GETS over the PSTN has shown the utility of alternate paths 
to a destination to help facilitate emergency-related communications. This is 
done at the application layer, independent of any lower layer rerouting 
(SONET rings, etc) that naturally applies to all traffic using the link, 
whether emergency or normal. Application of emergency telephony services to 
the Internet (and IP in general) means that there are two separate issues to 
be addressed.

a) IP Packet Transport layer: Unlike the PSTN, which creates a fixed path 
(circuit) during call setup phase, the Internet uses dynamic routing for IP 
packets. This dynamic routing capability automatically causes IP packets to 
travel the best current path, which may change during the life of the "call" 
due to failures of infrastructure components. However, at the time of "call" 
set up (at the application layer), the route choice for the packet transport 
layer has a single choice (the best current one). An issue to be addressed is 
the utility and possibility of providing additional routes (even is less 
efficient) for packet flows for higher priority "calls".

b) Call application layer:  The Internet infrastructure itself does not have 
the concept of a "call" or the concept of "call setup", although IP telephony 
applications using it would have application-layer awareness of calls or the 
call setup concept. Alternate path routing at the application layer may be 
useful in choosing one of possibly several egress points to the PSTN from the 
Internet.

Mike Pierce
Artel

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 13 Dec 2002 13:10:28 +0000

> automatically rerouted if a router becomes unavailable (even though this
> is useful to maintain a connection when a failure occurs). It is that,
> while the packets for a normal traffic might follow a specific,
> efficient path (to setup a new connection), the packets for an ETS call
> should attempt additional routes (even if very inefficient) which the
> normal call does not if there is congestion on the normal route. (Yes, I
> know all the arguments about "congestion can't happen in the core", but
> it's been clearly admitted that it can occur on some access links where
> alternate routing could also be used.)

the original passage in section 4 does not make a reference to "existing
flows" versus new flows or calls -- ie, its not that specific.  and so
taken at a higher level, i would say that the original passage would
apply to both (new and existing flows) without citing the subject of
congestion.  I'd prefer not to get into specifics in this document
and instead push more extended discussions on these "Issues" to the
Framework document.

> The current second paragraph seems to limit the issue of "alternate
> routing" at the application layer to "choosing .. egress points to the
> PSTN". A significant issue for survivability and congestion handling in
> some networks could be the desire for abilities to alternate route
> around congestion within the IP portion. (The ability to reroute around
> failures is already assumed.)
>

ok, the intent was to present a point of reference as opposed to limit
the issue to the application layer.  it may be easier and simpler to
just remove the second paragraph than to rewrite the section and discuss
in more depth the areas that altenate path routing does/can exist. Again,
lets push this to the Framework document.

-ken

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 08:29:13 -0500

On Thursday, Dec 12, 2002, at 16:47 America/Montreal, [email-masked] 
wrote:
> 1) The point in alternate routing for ETS is not that existing flows 
> are automatically rerouted if a router becomes unavailable (even 
> though this is useful to maintain a connection when a failure occurs). 
> It is that, while the packets for a normal traffic might follow a 
> specific, efficient path (to setup a new connection), the packets for 
> an ETS call should attempt additional routes (even if very 
> inefficient) which the normal call does not if there is congestion on 
> the normal route. (Yes, I know all the arguments about "congestion 
> can't happen in the core", but it's been clearly admitted that it can 
> occur on some access links where alternate routing could also be > used.)
>
> PSTN". A significant issue for survivability and congestion handling 
> in some networks could be the desire for abilities to alternate route 
> around congestion within the IP portion. (The ability to reroute 
> around failures is already assumed.)

The clarity is helpful and appreciated, but please see Joel Halpern's 
previous
commentary on QoS-based routing.  There is significant negative 
experience with
routing schemes that try to include congestion as part of the routing 
metric.
What happens is an oscillation where traffic switches from link A to 
link B
because A is getting full, then link B gets full, and the traffic all 
switches
back.  A better approach, that is widely available today, is to use 
other
techniques (within a domain, ECMP is one example or MPLS-TE might be 
another).

> sub-parts to address the two "layers" within IP and relate each to 
> what the PSTN did (or couldn't do) as follows:
>
> 1) Alternate paths
>
> Experience with GETS over the PSTN has shown the utility of alternate 
> paths to a destination to help facilitate emergency-related 
> communications. This is done at the application layer, independent of 
> any lower layer rerouting (SONET rings, etc) that naturally applies to 
> all traffic using the link, whether emergency or normal. Application 
> of emergency telephony services to the Internet (and IP in general) 
> means that there are two separate issues to be addressed.

What do you mean by "application-layer" and "alternate paths" ?

In the case of the Internet, path selection is an IP-layer function 
performed
by the routing system, not an application-layer function.

> a) IP Packet Transport layer: Unlike the PSTN, which creates a fixed 
> path (circuit) during call setup phase, the Internet uses dynamic 
> routing for IP packets. This dynamic routing capability automatically 
> causes IP packets to travel the best current path, which may change 
> during the life of the "call" due to failures of infrastructure 
> components. However, at the time of "call" set up (at the application 
> layer), the route choice for the packet transport layer has a single 
> choice (the best current one). An issue to be addressed is the utility 
> and possibility of providing additional routes (even is less 

I definitely don't follow what you are trying to get at above.  Please 
try to
explain in more detail what you are trying to do here.

> b) Call application layer:  The Internet infrastructure itself does 
> not have the concept of a "call" or the concept of "call setup", 
> although IP telephony applications using it would have 
> application-layer awareness of calls or the call setup concept. 
> Alternate path routing at the application layer may be useful in 
> choosing one of possibly several egress points to the PSTN from the 
> Internet.

Please explain what "alternate path routing at the application layer" 
is or
might be, with reference to the usual Internet Architecture.