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

From: [email-masked]
Date: Fri, 13 Dec 2002 13:17:28 EST

In a message dated 12/13/2002 8:30:02 AM Eastern Standard Time, 
[email-masked] writes:

On Thursday, Dec 12, 2002, at 16:47 America/Montreal, [email-masked] 
wrote:
<snip>

[RJA] 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).

[MAP] I understand the dificulty. That is why the existing text is in the 
"Issues" section of the draft, not in the "Requirements". The draft says 
"this utility may be difficult to achieve", so I read that to say "it might 
be possible". I didn't propose changing that idea.

[MAP]
> 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.

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

[MAP] See comment below.

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

[MAP} Which is mainly why I made the (somewhat editorial) suggestion to split 
the text into two sub-sections, to address the two layers separately. I think 
a lot of our disagreement is that I make statements pertaining to the 
"application layer" and some immediately think about the IP-layer. (like most 
of the discussion about Accounting).

[MAP]
> 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 if less 
> efficient) for packet flows for higher priority "calls".

[RJA] 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.

[MAP] I presume your question is related to the final sentence, since the 
rest were either copied direct from the draft or are simple statements of 
fact. I believe the final sentence, which relates to the possiblity of 
providing methods to have additional routes for the packet flows for 
emergency traffic, is straigthforward (to descibe, not necessarily to 
actually do). If it can't do something similar, then this would be one area 
in which the Internet would be inferior to the PSTN.

It has been identified that there is no capability in the Internet to route 
around congestion. Emergency service users believe they have a need for this 
capability ("requirement", in their vocabulary).

[MAP]
> 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.

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

[MAP] The above sentence about "alternate path routing at the application 
layer" was copied verbatim from the draft (which has your name on it). I was 
simply putting it under a heading that said "Call application layer". What 
did it mean in the original draft?

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 15:49:03 -0500

> of the discussion about Accounting).

I'm absolutely an IP-layer kind of person.  So unless something has a 
clearly
marked layer, my head will pretty much always start with the IP layer.

And it would help the Accounting thread if you'd call it "SIP 
Accounting"
if the scope is limited to SIP or "Application-layer accounting" if the
scope is limited to stuff in the application-layer.  This was not clear
either from the presentation or from previous discussions.  I'd still
like to understand what specific things one is trying to perform
accounting upon.

> in which the Internet would be inferior to the PSTN.

Lets avoid flamage.  I'll silently s/inferior/different/ for everyone's 
sanity.

> capability ("requirement", in their vocabulary).

Actually, from your earlier note today, maybe that means that DoD IP 
network
standards folks believe they have a need for this.  If I understood 
your note
earlier correctly, you are concerned with the military scenario, rather 
than the
civilian IEprep scenario.  At least some folks working at/with NCS do 
not
seem to believe that NCS needs a capability for IEprep to route around 
congestion
as long as there is appropriate system engineering so that congestion 
can't
occur in a given place.

And routing around "access links", which is where the congestion really 
might
live, generally means buying a parallel link for openers.  Because 
unless
there is some other link, no other path exists.  And a colloquial term 
for
"access link" is "tail circuit".   If a second path exists, then that 
path
will be known via the routing system.  In a whole lot of cases (most 
cases
of the deployed Internet), there is no second circuit.  For example, if
the T1 into my office goes down or gets congestion, I'm in trouble 
because
there is no other path here that could be used.

> did it mean in the original draft?

Out of context, it wasn't clear to me what was meant.  Those particular 
words
(like most of them in either draft) were Ken's, so I'll let Ken explain
(lest I botch the job and muddy the waters more thoroughly than usual 
:-).

Ran
[email-masked]