Subject: [Ieprep] American Red Cross using VoIP?
From: [email-masked] [mailto:[email-masked]] On Behalf Of King, Kimberly S.
To: Ieprep (E-mail)

According to this article, the Red Cross is using VoIP.
http://www.telecomweb.com/satellite/viasatellite/current/exclusive11.htm

Furthermore, their system appears to have nice properties:

"... the ARC has made the switch to Cisco Voice-over-IP (VoIP)
telephony."
--it supports packet voice

"Based on the Ford Excursion SUV, the Linx allows Red Cross workers to
drive to the scene fast" 
-- it supports mobility 

"the Linx can also help police, fire and EMS units with incompatible
radios talk to each other, through its onboard JPS Communications
ACU-1000 Modular Interconnect System. As well, the Linx can support
two-way radio, landline and cellular telephone communications on
scene. "  
-- it's interoperable with legacy systems

"Once there, we were able to provide 48 phone lines, email and
high-speed Internet access at Ground Zero, at a time when conventional
cell and landline phones were down."  "It can even capture live video
and send it back to Falls Church for real-time assessment by top Red
Cross staff."  
-- it supports many applications and provides Internet access

Kimberly

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 02, 2003 11:45 PM
To: [email-masked]; [email-masked]
Subject: RE: [Ieprep] American Red Cross using VoIP?

Although there are many points in this article that are not exactly
correct.
The fact that we (ARC) are using VOIP over VSAT is correct.

Hi all my name is David Craig and I'm the original designer of the CRV
Communications Response Vehicle referred to in this article as the
Linxs.

I am also the lead for ARC program to bring WAN (VSAT) VOIP and computer
connectivity to every Disaster.

We currently have 9 CRVs and 25 Flyaway systems that deploy to
disasters.

If anyone would like specifics on VOIP on use in ARC disaster program
please let me know.

We currently use two Cisco Call Managers at  with 2 VG that can handle
64 PRIs at our HUB here in Falls Church, VA.

Cisco 7910 & 7920 (802.11b) phones are currently used in the field
connecting via VSAT; we also deploy a VG in the field to allow for 8 FXO
and 4 FXS ports.

Hope this will let the list know that VOIP is being used in real
emergency communications situations. Please keep of the good work of
Ieprep.

David A. Craig
American National Red Cross
Disaster Services 
8111 Gatehouse Rd 
Falls Church, VA 22042
(703) 206-7901
[email-masked]

-----Original Message-----
From: King, Kimberly  S.
To: Ieprep (E-mail)
Sent: 6/2/03 11:52 AM
Subject: [Ieprep] American Red Cross using VoIP?

According to this article, the Red Cross is using VoIP.
http://www.telecomweb.com/satellite/viasatellite/current/exclusive11.htm

Furthermore, their system appears to have nice properties:

"... the ARC has made the switch to Cisco Voice-over-IP (VoIP)
telephony."
--it supports packet voice

"Based on the Ford Excursion SUV, the Linx allows Red Cross workers to
drive
to the scene fast" 
-- it supports mobility 

"the Linx can also help police, fire and EMS units with incompatible
radios
talk to each other, through its onboard JPS Communications ACU-1000
Modular
Interconnect System. As well, the Linx can support two-way radio,
landline
and cellular telephone communications on scene. " 
-- it's interoperable with legacy systems

"Once there, we were able to provide 48 phone lines, email and
high-speed
Internet access at Ground Zero, at a time when conventional cell and
landline phones were down."
"It can even capture live video and send it back to Falls Church for
real-time assessment by top Red Cross staff."
-- it supports many applications and provides Internet access 

Kimberly

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of King, Kimberly S.
Sent: Tuesday, June 03, 2003 9:44 AM
To: [email-masked]'; [email-masked];
[email-masked]
Subject: RE: [Ieprep] American Red Cross using VoIP?

David,

Thank you very much for your reply.

>>If anyone would like specifics on VOIP on use in ARC disaster 
>>program please let me know.

Yes, anything you can share will be very much appreciated.

Are you sending your VoIP traffic in IP format over the satellite link?
For example, using DVB-RCS type modem with IP encapsulated in MPEG?

If so, is both voice/data converged over one satellite link or do you
maintain separate "channels" for voice and data?  

If everything is converged over an IP satellite link, have you done any
traffic prioritization at both ends of your satellite link such as using
a low-latency queue for voice traffic?

How is your voice quality?  Are conversations understandable?  Have you
selected particular codecs to work in this context or does the standard
G.711 meet your requirements?

Do you have any problems with your Internet connection?  Do you use any
TCP PEP enhancements for the satellite hop?  Are most problems in
Internet performance restricted to the satellite hop?

Is there some standard that you are missing that ieprep could help in
defining?  

Thank you for your input.

Kimberly

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>Sent: Monday, June 02, 2003 11:45 PM
>>To: [email-masked]; [email-masked]
>>Subject: RE: [Ieprep] American Red Cross using VoIP?
>>
>>
>>Although there are many points in this article that are not 
>>exactly correct.
>>The fact that we (ARC) are using VOIP over VSAT is correct.
>>
>>Hi all my name is David Craig and I'm the original designer of 
>>the CRV Communications Response Vehicle referred to in this 
>>article as the Linxs.
>>
>>I am also the lead for ARC program to bring WAN (VSAT) VOIP 
>>and computer connectivity to every Disaster.
>>
>>We currently have 9 CRVs and 25 Flyaway systems that deploy to 
>>disasters.
>>
>>If anyone would like specifics on VOIP on use in ARC disaster 
>>program please let me know.
>>
>>We currently use two Cisco Call Managers at  with 2 VG that 
>>can handle 64 PRIs at our HUB here in Falls Church, VA.
>>
>>Cisco 7910 & 7920 (802.11b) phones are currently used in the 
>>field connecting via VSAT; we also deploy a VG in the field to 
>>allow for 8 FXO and 4 FXS ports.
>>
>>Hope this will let the list know that VOIP is being used in 
>>real emergency communications situations. Please keep of the 
>>good work of Ieprep.
>>
>>
>>David A. Craig
>>American National Red Cross
>>Disaster Services 
>>8111 Gatehouse Rd 
>>Falls Church, VA 22042
>>(703) 206-7901
>>[email-masked]
>>
>>
>>

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Donelan
Sent: Sunday, June 15, 2003 8:16 PM
To: [email-masked]
Subject: [Ieprep] Traffic prioritization after Algeries earthquake

As you may know, the earthquake in Algeria also cut several
international fiber cables SE-ME-WE3 and FLAG on May 22 2003.  Some
providers lost up to 95% of their normal bandwidth capacity.
http://www.idgnews.net/intl/international.nsf/0/00256AF50054FFC100256D40
004A4DD2?OpenDocument

Internet access was not completely severed.  There were numerous
alternative routings brought up through regional exchange points and
some providers switched to backup satellite and connections to the
far east. But generally the backup connections had less capacity and
much
greater latency.

Providers such as Batelco prioritized mail service over other
Internet services, such as web browsing and voice calls.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 19, 2003 7:31 AM
To: IETF-Announce:
Cc: [email-masked]
Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-general-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Emergency Preparedness Working
Group of the IETF.

	Title		: General Requirements for Emergency
Telecommunication 
                          Service
	Author(s)	: K. Carlberg, R. Atkinson
	Filename	: draft-ietf-ieprep-ets-general-03.txt
	Pages		: 10
	Date		: 2003-6-18
	
This document presents a list of general requirements in support of
Emergency Telecommunications Service (ETS). Solutions to these
requirements are not presented in this document.  Additional
requirements pertaining to specific applications, or types of
applications, are to be specified in separate document(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-ets-general-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ieprep-ets-general-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ieprep-ets-general-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 19, 2003 7:31 AM
To: IETF-Announce:
Cc: [email-masked]
Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Emergency Preparedness Working
Group of the IETF.

	Title		: IP Telephony Requirements for Emergency 
                          Telecommunication Service
	Author(s)	: K. Carlberg, R. Atkinson
	Filename	: draft-ietf-ieprep-ets-telephony-05.txt
	Pages		: 6
	Date		: 2003-6-18
	
This document presents a list of requirements in support of Emergency
Telecommunications Service (ETS) within the context of IP telephony.
It is an extension to the general requirements presented in [3].
Solutions to these requirements are not presented in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-ets-telephony-05.t
xt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ieprep-ets-telephony-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ieprep-ets-telephony-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 23, 2003 1:25 PM
To: [email-masked]
Subject: [Ieprep] Congestion avoidance
 
To all, 

About a half year ago there was a discussion about congestion avoidance
(rerouting around congestion) including the issues of: 

1. Is there a requirement to route around congestion? 
2. Is there any current "standardized" way to route around congestion? 
3. Is there any possibility of defining a way to route around
congestion? 
4. Would any such attempt lead to disaster? 

I did not see a conclusion to that discussion. The issue here generally
relates to the "path" to be used by a new packet flow being established
to support a new call. 

draft-ietf-iprep-ets-telephony-05 discusses the "issue" of alternate
paths and noted that "this utility may be difficult to achieve [in IP]"
while arguing that it is unnecesary since "dynamic routing automatically
causes IP packets to travel the best path". However, from previous
discussions, I understood that the determination of that path is not
affected by the traffic conditions (congestion or otherwise) present at
the moment the call is being setup. That means that, if a particular
path (transport facility between two routers) is already congested, the
new packet flow will be blindly established across the same path,
thereby making the situation worse. (Note the situation described here
is not the one of ETS or Assured Service. It addresses the case when all
the calls being setup are equal.) 

For the case of Assured Service and ETS, I believe the answer to #1
above is Yes. 

Has anyone thought further on the possibilities of addressing this
issue? 

Mike Pierce 
Artel 

From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: Monday, June 23, 2003 1:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ieprep] Congestion avoidance

On Monday, Jun 23, 2003, at 13:25 America/Montreal, [email-masked] 
wrote:

>> About a half year ago there was a discussion about congestion

avoidance

>> (rerouting around congestion) including the issues of:
>>
>> 1. Is there a requirement to route around congestion?
>> 2. Is there any current "standardized" way to route around congestion?
>> 3. Is there any possibility of defining a way to route around 
>> congestion?
>> 4. Would any such attempt lead to disaster?

...

>> For the case of Assured Service and ETS, I believe the answer to #1 
>> above is Yes.

If one thinks that the answer to #1 is Yes and if one believe that the
current approaches (discussed at length in the past; see archives, since
no point in rehashing old ground again) are not sufficient, then my own
(quite serious) suggestion would be to not use the Internet for that 
traffic.

For my own part, I think that the question #1 is mis-phrased at best
(not least because there is broad understanding here that the congested
links are virtually always the access uplinks -- where no alternate path
EXISTS -- and the congested links are virtually never the core links).

Further, I think that current approaches (e.g. CBQ in the access router
to apply the policy of the operator of the congested access link,
DiffServ within a single administrative domain) are more than sufficient
to meet the actual congestion issues that might exist.

Joel Halpern and others have commented on (2), (3), and (4) in the past,
as I recall.  I don't think the physics have changed in the last 6
months, so I believe their earlier analyses still apply.  Other folks'
mileage might vary from mine, of course.

Ran
[email-masked]

NB:  In the above, "operator" means any operator, not just an ISP.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ayyasamy, Senthilkumar (UMKC-Student)
Sent: Monday, June 23, 2003 3:46 PM
To: RJ Atkinson; [email-masked]
Cc: [email-masked]
Subject: RE: [Ieprep] Congestion avoidance

>>>> 1. Is there a requirement to route around congestion?
>
>>
>>If one thinks that the answer to #1 is Yes and if one believe that the
>>current approaches (discussed at length in the past; see archives,

since

>>no point in rehashing old ground again) are not sufficient, then my own
>>(quite serious) suggestion would be to not use the Internet for that 
>>traffic.

I strongly agree with Ran. All current Internet Routing Protocols (OSPF,

BGP etc.,) at best take a pro-active approach. In 1998, a dynamic metric
(delay) was proposed for ARPANET, but lead to lot of oscillatory
problems.  Also, reactive routing protocols are prone to instability. If
one comes up with such a *deployable, incremental* traffic aware
proposal in current routing protocol, we don't have to depend on
TE/OMP/MPLS sort of solutions. 

Extending OSPF for adaptiveness is easy, when compared with BGP. First, 
choose a available bw inference technique, find alternate paths based on
available bw information from router (Floyd's Quick start feedback),
then calculate Link utilization as an moving point average of the
load. Then,

work on patches for oscillatory problems. Else, use means of OMP/ECMP/
MPLS/tweaking OSPF weights. I am not sure, but the extra work (probing
to learn available bw from TCP, heuristics to neutralize the
oscillation, then load balance effectively) seems a big overhead when
compared to proactive, static routing.

BGP is a bigger system; so reactive proposal seems an infeasible option.
Hi, Noel designed NIMROD with DSR for choosing the whole AS path. But,
it delegates too much control to user. But, it was not considered for
IPng a rchitecture, as it was classified as *too much research* and
source routing is not enabled in most routers. As we discussed in IMRG,
a lot of smart routing vendor products (from routescience, nexthop
etc..) helps to address the access congestion problem by allowing to
choose the first hop of the best route.

A current feasible option seems to be overlay based. We can do the above
mentioned steps  by application based/congestion aware routing schemes.
If DISA is really serious about this issue; then talk with akamai for 
getting a subscription to their akaedgesuite. It does all the wonders of
re-routing based on congestion. They maintain unique data centers, 
measurement overlay points and active pinging strategy to find the best
path to route around congestion.

Their are strong research issues to be hashed here... How many physical
damages and fiber cuts lead to serious routing changes?? How to share
the delay information with application layer? how routing and congestion
interacts? Uwash/MIT has hashed some of these issues through RON/Detour
projects. This area is a fertile ground to concentrate...At last, we
grad students needs some work 

If your worried about standardization/deployment... forget it. We still 
don't have a simple load balancing mechanism standardized yet. The only 
feasible option seems to be early exit -aka hot potato routing. Load 
balancing in inter-domain seems a lot of work ( inbound/outbound load 
balancing between peering links/ transit links or a mix of peering&
transit). IETF WG Multi6 indirectly address some of these issues. 

Architectural issue: 

 A lot of layering/functional interactions can be observed in current
Internet. Routing and congestion seems to have lot of interacting 
junctions ( as mentioned above...) But, I don't know, how much 
interaction level should be allowed. A total reactive based routing 
means- congestion and routing has reached the highest interaction
point. But, I strongly agree with Ran's statement that, "not use the 
Internet for [route-around-congestion] traffic.

PS: I have not considered QoS routing, QoS routing extension for 
OSPF and TE extensions etc..

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 23, 2003 4:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ieprep] Congestion avoidance
 
In a message dated 6/23/2003 1:51:24 PM Eastern Standard Time,
[email-masked] writes: 

On Monday, Jun 23, 2003, at 13:25 America/Montreal, [email-masked] 
wrote: 

>> About a half year ago there was a discussion about congestion

avoidance 

>> (rerouting around congestion) including the issues of: 
>> 
>> 1. Is there a requirement to route around congestion? 
>> 2. Is there any current "standardized" way to route around congestion?

>> 3. Is there any possibility of defining a way to route around 
>> congestion? 
>> 4. Would any such attempt lead to disaster? 

... 

>> For the case of Assured Service and ETS, I believe the answer to #1 
>> above is Yes. 

If one thinks that the answer to #1 is Yes and if one believe that the 
current approaches (discussed at length in the past; see archives, since
no point in rehashing old ground again) are not sufficient, then my own 
(quite serious) suggestion would be to not use the Internet for that 
traffic. 

For my own part, I think that the question #1 is mis-phrased at best 
(not least because there is broad understanding here that the congested 
links are virtually always the access uplinks -- where no alternate path
EXISTS -- and the congested links are virtually never the core links). 

Further, I think that current approaches (e.g. CBQ in the access router
to apply the policy of the operator of the congested access link,
DiffServ within a single administrative domain) are more than sufficient
to meet the actual congestion issues that might exist. 

Joel Halpern and others have commented on (2), (3), and (4) in the past,
as I recall.  I don't think the physics have changed in the last 6
months, so I believe their earlier analyses still apply.  Other folks'
mileage might vary from mine, of course.

Ran 
[email-masked] 

Ran, 

Thanks for the response. I was afraid that no one was interested enough
anymore to take the time to respond. 

No, I don't want to rehash old ground. I'd like to understand the
result. I think there are several issues. 

Even if we concentrate on the "access", since many do not believe that
any network could possibly have congestion in the core, there seems to
be a misunderstanding of what "access" means. In any robust, survivable
network, even the "access" would have redundant paths/links/ or whatever
you want to call them. It is not true as you state that "no alternate
path EXISTS". That means that there is the possibility of congestion on
some of those "access" links and there is a need to route around that
congestion, that is, use other redundant links when setting up the path
for a new packet flow to follow (or, better yet, to change the path of a
flow in the middle of a call) based on a knowledge of the current
loading. 

Incidentally, some of us continue to believe that the networks we are
concerned about could occasionlly have congestion in the core, and you
seem to support this idea with your statement above that "congested
links are virtually never the core links". ("Virtually", not "never".) 

My understanding of the comments made before, by Joel Halpern and
others, was that: 

1. No, there are not any defined ways to dynamically route around
congestion 
2. Any attempt to do so would lead to (worse) disaster. (I believe this
statement) 

I was asking if this is still the consensus. If it is, then I need to
recommend to the people I am trying to advise, that, following your
suggestion above, that their best approach would be "to not use the
Internet for that traffic". However, I have to assume you meant
"Internet Protocol" rather than "the Internet". 

Mike Pierce 

From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: Monday, June 23, 2003 5:46 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ieprep] Congestion avoidance

On Monday, Jun 23, 2003, at 16:58 America/Montreal, [email-masked] 
wrote:

>> Even if we concentrate on the "access", since many do not believe that

>> any network could possibly have congestion in the core, there seems to

>> be a misunderstanding of what "access" means. In any robust, 
>> survivable network, even the "access" would have redundant 
>> paths/links/ or whatever you want to call them. It is not true as you 
>> state that "no alternate path EXISTS". That means that there is the 
>> possibility of congestion on some of those "access" links and there is

>> a need to route around that congestion, that is, use other redundant 
>> links when setting up the path for a new packet flow to follow (or, 
>> better yet, to change the path of a flow in the middle of a call) 
>> based on a knowledge of the current loading.

As noted in previous discussions, there are various technology 
approaches
that can be adopted.  These approaches necessarily vary with the exact 
topology
being discussed.

To give merely one example, if the access link is intra-domain (not 
unlikely
if one considers DoD's NIPRnet), then OSPF multi-path (which is openly 
specified)
will prevent any single link from being congested when there are 2 or 
more links
between routers A and B  && the offered load does not exceed capacity.

It might focus discussion if you could be very specific about the 
details
of the scenario you are concerned with.

>> Incidentally, some of us continue to believe that the networks we are 
>> concerned about could occasionlly have congestion in the core, and you

>> seem to support this idea with your statement above that "congested 
>> links are virtually never the core links". ("Virtually", not "never".)

I'd never build a core that could get congested, but I'm not the only 
person
who has ever designed a network, so I didn't want to speak for all 
network
designers.

Not entirely clear to me which networks you are concerned about though,
maybe you could be more specific.

>> I was asking if this is still the consensus. If it is, then I need to 
>> recommend to the people I am trying to advise, that, following your 
>> suggestion above, that their best approach would be "to not use the 
>> Internet for that traffic". However, I have to assume you meant 
>> "Internet Protocol" rather than "the Internet".

No, I meant Internet, not IP.  Within a single domain, there are a 
variety
of techniques for avoiding congestion (one example above) that can work 
well.
Which of these is applicable varies with the exact network topology.

It is possible to design a network such that it is resilient.  It is 
also
possible to design a netework such that it is not resilient.  If the 
network
is poorly designed, the first step is to fix the design.  And this is 
true
regardless of whether one is building a PSTN, an Internet, or something 
quite
different from either. 

Cheers,

Ran Atkinson
[email-masked]

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 24, 2003 7:00 AM
To: IETF-Announce:
Cc: [email-masked]
Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Emergency Preparedness Working
Group of the IETF.

	Title		: Framework for Supporting IEPS in IP Telephony
	Author(s)	: K. Carlberg, I. Brown, C. Beard
	Filename	: draft-ietf-ieprep-framework-05.txt
	Pages		: 27
	Date		: 2003-6-23
	
This document presents a framework for supporting authorized
emergency related communication within the context of IP telephony.
We present a series of objectives that reflect a general view of how
authorized emergency service, in line with the Emergency
Telecommunications Service (ETS), should be realized within today's
IP architecture and service models.  From these objectives, we
present a corresponding set of protocols and capabilities, which
provide a more specific set of recommendations regarding existing
IETF protocols.  Finally, we present two scenarios that act as
guiding models for the objectives and functions listed in this
document.  These, models, coupled with an example of an existing
service in the PSTN, contribute to a constrained solution space.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-framework-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ieprep-framework-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ieprep-framework-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Carlberg
Sent: Tuesday, June 24, 2003 9:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ieprep] Congestion avoidance

>> Has anyone thought further on the possibilities of addressing this

issue?
 
in the IP Telephony Framework document we discuss the area of alternate
path routing and point the reader to only two places: intra-domain and
application layer routing.  we purposely do not discuss BGP nor even
ask the reader to consider that area.  

In the case of intra-domain, we cite the work of RFC 2543, "Framework 
for MPLS-based Recovery".  its motivation is to provide fault tolerance 
within the network.  its not exactly re-routing based on metrics, but 
indirectly it may be of help in what you are looking for.  of course, 
MPLS can be considered a bit monstrous and somewhat of overkill, and 
thats part of the tradeoff in basing a deployment on it.  Note: the IP
Telephony framework document also states that MPLS may or may not exist 
in a given domain -- so, don't count on its existance along an 
end-to-end path.
 
the second example is RFC 3219 "Telephony Routing over IP (TRIP)".
this can be considered a form of application layer routing, albeit
at a much constrained perspective.  

-ken

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Carlberg
Sent: Tuesday, June 24, 2003 9:55 AM
To: [email-masked]
Subject: [Ieprep] new drafts

a new version of the IP Telephony Framework draft has been placed in 
the I-D repositories.  the major change in the draft involves a
complete rewrite of the objectives section.  from private email, 
there still seemed to be some confusion between the relation of it 
to the section on Protocols & Mechanisms (the heart of the draft).  So
I removed most of the old objectives and added a section on 
"considerations" -- ie, some brief thoughts to keep in mind.

I've also submitted two new (-00) individual contributions that focus
only on stub domains.  the first, draft-carlberg-ets-req-stub-00.txt,
is a requirements draft and has been posted.  the other is a framework 
draft, draft-carlberg-ets-stub-frame-00.txt, and should be posted by the
I-D editor shortly.  both of these drafts have place holders for
subjects 
that need more thought out.  the drafts stem in part from discussion on 
the subject at the last working group email and from subsequent personal
discussions.

-ken

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Tuesday, June 24, 2003 10:35 AM
To: Ken Carlberg
Cc: [email-masked]; [email-masked]
Subject: Re: [Ieprep] Congestion avoidance

Ken Carlberg wrote:

>> the second example is RFC 3219 "Telephony Routing over IP (TRIP)".
>> this can be considered a form of application layer routing, albeit
>> at a much constrained perspective.  

Careful here. TRIP routes IP telephony *signaling*, not media. Media 
traverses whatever path L3 routing sets up.

There is recent technical work on true application-layer routing,
including

Atanu Ghosh, Michael Fry, and Jon Crowcroft, "An Architecture for 
Application Layer Routing", in International Working Conference on 
Active Networks (IWAN), Philadelphia, Pennsylvania, September/October 
2001. [Ghos01:Architecture]

and

  Weidong Cui, Ion Stoica, and Randy H. Katz, "Backup Path Allocation 
Based on a Correlated Link Failure Probability Model in Overlay 
Networks", in ICNP 2002, November 2002. [Cui0211:Backup]

and

David G. Andersen, Hari Balakrishnan, M. Frans Kaashoek, and Robert 
Morris, "Resilient Overlay Networks", in 18th ACM SOSP, Banff, Canada, 
October 2001. [Ande0110:Resilient]

among many others. Search for 'overlay routing' in netbib.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Carlberg
Sent: Tuesday, June 24, 2003 10:50 AM
To: Henning Schulzrinne
Cc: [email-masked]; [email-masked]
Subject: Re: [Ieprep] Congestion avoidance

>> Careful here. TRIP routes IP telephony *signaling*, not media. Media 
>> traverses whatever path L3 routing sets up.

yes, quite correct.  in Pierce's original email he refered to
"call setup", so I probably should have added that reference to 
my previous response.

-ken

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Tuesday, June 24, 2003 10:57 AM
To: Ken Carlberg
Cc: [email-masked]; [email-masked]
Subject: Re: [Ieprep] Congestion avoidance

Ken Carlberg wrote:

>>>>Careful here. TRIP routes IP telephony *signaling*, not media. Media 
>>>>traverses whatever path L3 routing sets up.
>
>> 
>> 
>> yes, quite correct.  in Pierce's original email he refered to
>> "call setup", so I probably should have added that reference to 
>> my previous response.

In other words, TRIP doesn't help with network congestion unless you can

route the call to a different part of the network which is in better 
shape AND if the TRIP nodes have any clue as to the network state. The 
latter seems quite unlikely and is certainly not part of the TRIP 
framework. (It is unlikely since there's no guarantee whatsoever that 
the TRIP nodes are anywhere close to the datapath. A TRIP node for a 
gateway or set of gateways in France can be in New Zealand.) TRIP can 
help with gateway congestion or maybe congestion very close to the 
gateway, e.g., on its access link, that the gateway can report on. Thus,

I think mentioning TRIP in this context seems likely to raise false 
expectations. I don't know which document mentions it, but I would 
recommend striking it unless you're talking specifically about *gateway*

congestion, i.e., lack of circuit-switched capacity.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Tuesday, June 24, 2003 10:57 AM
To: Ken Carlberg
Cc: [email-masked]; [email-masked]
Subject: Re: [Ieprep] Congestion avoidance

Ken Carlberg wrote:

>>>>Careful here. TRIP routes IP telephony *signaling*, not media. Media 
>>>>traverses whatever path L3 routing sets up.
>
>> 
>> 
>> yes, quite correct.  in Pierce's original email he refered to
>> "call setup", so I probably should have added that reference to 
>> my previous response.

In other words, TRIP doesn't help with network congestion unless you can

route the call to a different part of the network which is in better 
shape AND if the TRIP nodes have any clue as to the network state. The 
latter seems quite unlikely and is certainly not part of the TRIP 
framework. (It is unlikely since there's no guarantee whatsoever that 
the TRIP nodes are anywhere close to the datapath. A TRIP node for a 
gateway or set of gateways in France can be in New Zealand.) TRIP can 
help with gateway congestion or maybe congestion very close to the 
gateway, e.g., on its access link, that the gateway can report on. Thus,

I think mentioning TRIP in this context seems likely to raise false 
expectations. I don't know which document mentions it, but I would 
recommend striking it unless you're talking specifically about *gateway*

congestion, i.e., lack of circuit-switched capacity.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Carlberg
Sent: Tuesday, June 24, 2003 11:14 AM
To: Henning Schulzrinne
Cc: [email-masked]; [email-masked]
Subject: Re: [Ieprep] Congestion avoidance

>> In other words, TRIP doesn't help with network congestion unless you

can 

>> route the call to a different part of the network which is in better 
>> shape AND if the TRIP nodes have any clue as to the network state.

this is true for any application layer routing.  routes are not
guaranteed and should never be expected to be congruent when you 
'route' at a different layer.  

we even see this with network overlays like the Mbone in comparison to
the underlying unicast routing.  and actually, unless routing is 
completely flat, one can argue that IP routing as it exists today cannot

truly route at a given level around all possible congestion points.  
but this gets us into a rat hole. 

>> The 
>> latter seems quite unlikely and is certainly not part of the TRIP 
>> framework. (It is unlikely since there's no guarantee whatsoever that 
>> the TRIP nodes are anywhere close to the datapath. A TRIP node for a 
>> gateway or set of gateways in France can be in New Zealand.) TRIP can 
>> help with gateway congestion or maybe congestion very close to the 
>> gateway, e.g., on its access link, that the gateway can report on.

Thus,

>> I think mentioning TRIP in this context seems likely to raise false 
>> expectations. I don't know which document mentions it, but I would 
>> recommend striking it unless you're talking specifically about

*gateway* 

>> congestion, i.e., lack of circuit-switched capacity.

TRIP is never mentioned as routing over the datapath, so the false 
expectations you are concerned with are not really present.  however,
to ensure that confusion doesn't linger, we can add more verbage to
reinforce the points you bring up and remove the possibility for 
confusion.

-ken

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: Tuesday, June 24, 2003 11:12 AM
To: ieprep
Subject: Re: [Ieprep] Congestion avoidance

On Tuesday, Jun 24, 2003, at 10:35 America/Montreal, Henning 
Schulzrinne wrote:

>> There is recent technical work on true application-layer routing, 
>> including

There has also been a lot of work (and some IETF standards) in the
"traffic engineering" area.  Much of that is also applicable to the
general topic that has been raised.  grep indicates there are both
a number of RFCs and a number of current I-Ds on the topic of traffic
engineering.

And I still think that [VJ88] is entirely relevant when considering
the overall question of Internet congestion avoidance and control,
though I entirely share the congestion avoidance behavioural concerns
of Sally Floyd et alia regarding currently deployed IP telephony 
systems.

Ran Atkinson
[email-masked]

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ayyasamy, Senthilkumar (UMKC-Student)
Sent: Tuesday, June 24, 2003 1:43 PM
To: RJ Atkinson; ieprep
Subject: RE: [Ieprep] Congestion avoidance

>>And I still think that [VJ88] is entirely relevant when considering
>>the overall question of Internet congestion avoidance and control,
>>though I entirely share the congestion avoidance behavioural concerns
>>of Sally Floyd et alia regarding currently deployed IP telephony 
>>systems.

http://www.icir.org/floyd/papers/draft-iab-congestion-00.txt

I guess, it will take sometime to appear in id-action

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Berg, Dennis
Sent: Wednesday, June 25, 2003 7:54 AM
To: 'Ken Carlberg'
Cc: [email-masked]
Subject: RE: [Ieprep] Framework for ETS in IP Telephony 05
 
Ken, 
The 05 revision of the Framework still has the following incorrect
statement (in the "Note" at the end of 4.3) that I pointed out in the
comments I recently sent you on the document.  You state that some SLAs
specify a maximum amount of priority traffic, then say:
        
Once this limit is reached, all other GETS calls experience the same 
probability of call completion as the general public.  
This is not ture. The following (the revision I proposed to you in my
comments) is the accurate description: 
Note: As a point of reference, some of the existing SLAs established by
the NCS for GETS service include a loosely-defined maximum allocation of
(e.g., 1-10%)priority traffic that a given LEC is obligated to carry.
However, in the LECs, there is no system function that monitors the
level of priority traffic and takes action in the event that this
maximum allocation is exceeded. As long as the proportion of priority
traffic is relatively small, i.e., in the 1-10% range, nothing more
specific or elaborate is needed; however, if this portion ever became
significantly larger, then some systematic response to limiting priority
traffic would be appropriate.  In fact, in the extension of GETS to
wireless networks, because radio resources are so scarce and wireless
telephones, being mobile, can converge on a specific limited radio
resource, a systematic function to limit the amount of traffic given
priority has been implemented in order to protecting non-priority
traffic. 
Please correct this statement. It is important not to propagate a view
that a throttle function for priority traffic is always required.
Dennis 
-----Original Message----- 
From: Ken Carlberg [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2003 9:55 AM 
To: [email-masked] 
Subject: [Ieprep] new drafts 
 
a new version of the IP Telephony Framework draft has been placed in 
the I-D repositories.  the major change in the draft involves a 
complete rewrite of the objectives section.  from private email, 
there still seemed to be some confusion between the relation of it 
to the section on Protocols & Mechanisms (the heart of the draft).  So 
I removed most of the old objectives and added a section on 
"considerations" -- ie, some brief thoughts to keep in mind. 
I've also submitted two new (-00) individual contributions that focus 
only on stub domains.  the first, draft-carlberg-ets-req-stub-00.txt, 
is a requirements draft and has been posted.  the other is a framework 
draft, draft-carlberg-ets-stub-frame-00.txt, and should be posted by the

I-D editor shortly.  both of these drafts have place holders for
subjects 
that need more thought out.  the drafts stem in part from discussion on 
the subject at the last working group email and from subsequent personal

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

------=_NextPart_000_002A_01C33BEB.9EE27360
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<title>RE: [Ieprep] Framework for ETS in IP Telephony 05</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:ApplyBreakingRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf Of </span></b>Berg,
Dennis<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 25, =
2003
7:54 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Ken Carlberg'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [Ieprep] =
Framework
for ETS in IP Telephony 05</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Ken, </span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The 05
revision of the Framework still has the following incorrect statement =
(in the
&quot;Note&quot; at the end of 4.3) that I pointed out in the comments I
recently sent you on the document.&nbsp; You state that some SLAs =
specify a
maximum amount of priority traffic, then =
say:</span></font><o:p></o:p></p>

<p><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
</span></font><font size=3D2><span style=3D'font-size:10.0pt'>Once this =
limit is
reached, all other GETS calls experience the same</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>probability of call =
completion as
the general public.&nbsp; </span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>This is
not ture. The following (the revision I proposed to you in my comments) =
is the
accurate description:</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Note: As
a point of reference, some of the existing SLAs established by the NCS =
for GETS
service include a loosely-defined maximum allocation of (e.g., =
1-10%)priority
traffic that a given LEC is obligated to carry.&nbsp; However, in the =
LECs,
there is no system function that monitors the level of priority traffic =
and
takes action in the event that this maximum allocation is exceeded. As =
long as
the proportion of priority traffic is relatively small, i.e., in the =
1-10%
range, nothing more specific or elaborate is needed; however, if this =
portion
ever became significantly larger, then some systematic response to =
limiting
priority traffic would be appropriate.&nbsp; In fact, in the extension =
of GETS
to wireless networks, because radio resources are so scarce and wireless
telephones, being mobile, can converge on a specific limited radio =
resource, a
systematic function to limit the amount of traffic given priority has =
been
implemented in order to protecting non-priority traffic. =
</span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Please
correct this statement. It is important not to propagate a view that a =
throttle
function for priority traffic is always =
required.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Dennis</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: Ken Carlberg [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a=

>>] </span></font><br>

<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Tuesday, June 24, =
2003 9:55
AM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: =
[email-masked]</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: [Ieprep] new =
drafts</span></font>
<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>a new
version of the IP Telephony Framework draft has been placed in =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>the I-D =
repositories.&nbsp; the
major change in the draft involves a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>complete rewrite of the =
objectives
section.&nbsp; from private email, </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>there still seemed to be =
some
confusion between the relation of it </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>to the section on =
Protocols &amp;
Mechanisms (the heart of the draft).&nbsp; So</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>I removed most of the =
old
objectives and added a section on </span></font><br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&quot;considerations&quot; -- ie,
some brief thoughts to keep in mind.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I've also
submitted two new (-00) individual contributions that =
focus</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>only on stub =
domains.&nbsp; the
first, draft-carlberg-ets-req-stub-00.txt,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>is a requirements draft =
and has
been posted.&nbsp; the other is a framework </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>draft,
draft-carlberg-ets-stub-frame-00.txt, and should be posted by =
the</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>I-D editor =
shortly.&nbsp; both of
these drafts have place holders for subjects </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>that need more thought =
out.&nbsp;
the drafts stem in part from discussion on </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>the subject at the last =
working
group email and from subsequent personal</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>discussions.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-ken</span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>______________________________________________=
_</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Ieprep mailing =
list</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>[email-masked]</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'><a
href=3D"https://www1.ietf.org/mailman/listinfo/ieprep" =
target=3D"_blank">https://www1.ietf.org/mailman/listinfo/ieprep</a></span=

>></font>

<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_002A_01C33BEB.9EE27360--

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Carlberg
Sent: Wednesday, June 25, 2003 10:18 AM
To: Berg, Dennis
Cc: [email-masked]
Subject: Re: [Ieprep] Framework for ETS in IP Telephony 05

my apologies.  in my rush to get out several documents I forgot to
add in several comments that you had sent to me.  they'll be added in
in a next version.

>> Please correct this statement. It is important not to propagate a view
>> that a throttle function for priority traffic is always required.

just a nit.  folks tend to get a bit concerned when they hear the word
"requirement".  We use the term "expected" and "encouraged" in the
passage to convey the hope that folks would establish a limit in the
resources set aside to support ETS traffic so as to avoid starving other
traffic.  but outside of that, we couldn't require others to follow that
course of action.  that would be local decision by those managing the
resources.

cheers,

-ken

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

From [email-masked]  Thu Jun 26 01:02:43 2003
Date: Thu, 26 Jun 2003 01:00:43 -0400 (EDT)
From: Sean Donelan <[email-masked]>
To: [email-masked]
Subject: Re: [Ieprep] Congestion avoidance
Sender: [email-masked]

On Mon, 23 Jun 2003 [email-masked] wrote:
> About a half year ago there was a discussion about congestion avoidance
> (rerouting around congestion) including the issues of:
>
> 1. Is there a requirement to route around congestion?
> 2. Is there any current "standardized" way to route around congestion?
> 3. Is there any possibility of defining a way to route around congestion?
> 4. Would any such attempt lead to disaster?
>
> I did not see a conclusion to that discussion. The issue here generally
> relates to the "path" to be used by a new packet flow being established
> to support a new call.

Would it be possible to avoid the use of the word congestion?  It has
a particular meaning in the telephony world, and different meaning in
the Internet world.

90% of today's Internet traffic depends on congestion being encountered
somewhere in the path.  Attempts in the 1980's to dynamically re-route
data traffic based on instaneous "congestion" resulted in spectacular
oscillations.  Saying you want to route around congestion gives me
bad flashbacks.

I think you are actually refering to call blocking in traditional circuit
switched networks.  Its an issue of admission control to the circuit
switched network.  If all the circuits are in use, new calls are blocked.
Re-routing means some circuit paths are kept in reserve.  It may be
obvious, but call setup only occurs at the start of the call.

With a packet switched network, making a decision at the bottleneck hop
to "re-route" a packet through a different interface is almost more
work than sending packet through the preferred interface.  It also avoids
those nasty forwarding loops which occur in hop-by-hop routing when the
routing paths oscillate.

But its a different situation at the call gateway.

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

From [email-masked]  Thu Jun 26 09:57:43 2003
Date: Thu, 26 Jun 2003 09:55:17 -0400
Subject: Re: [Ieprep] Congestion avoidance
Cc: [email-masked], [email-masked]
To: [email-masked]
From: RJ Atkinson <[email-masked]>
Sender: [email-masked]

On Thursday, Jun 26, 2003, at 08:43 America/Montreal, [email-masked] 
wrote:
> [SD] 90% of today's Internet traffic depends on congestion being 
> encountered
> somewhere in the path.  Attempts in the 1980's to dynamically re-route
> data traffic based on instaneous "congestion" resulted in spectacular
> oscillations.  Saying you want to route around congestion gives me
> bad flashbacks.
>
> [MAP] That's an interesting statement, considering past statements by 
> some
> that "congestion doesn't occur in the core". I think you're saying 
> that it's
> always there, we just deal with it.

The phrase "somewhere in the path" includes the edge in its scope,
and does NOT imply the core is congested.  Please don't misinterpret
what Sean actually said.

> I can understand the reason for "bad flashbacks", but that doesn't 
> resolve
> the basic need for any communications network to route around 
> "congestion". I
> believe that non-real time applications of packet transfer could just 
> wait until
> the packet got through. Real-time ("inelastic") applications such as 
> voice
> can't do that.

There is operational experience in the DoD (e.g. derived from work 
originally
done at NRL ITD) that says that VoIP in fact is an elastic application
-- if the right vocoders are used and sensible systems engineering 
happens
in the voice applications.  Those kinds of systems are in production use
today in the operational DoD, or so I'm told by folks who should know.
At least some senior folks within DISA staff know about this.

> But if  the routers just send the packets down a specific, 
> predeterimed path,

IP routing is dynamic, not predetermined, in the normal case.  And 
techniques
like OSPF ECMP (mentioned several times in the past) let routers spread 
traffic
across available links between routers A and B.  Also, as noted before, 
there
are various RFCs that describe traffic engineering techniques that 
might be
applicable -- depending on the details of the actual network being 
discussed,
of course.

Ran
[email-masked]

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

From [email-masked]  Thu Jun 26 09:58:34 2003
Date: Thu, 26 Jun 2003 09:56:58 -0400
From: RJ Atkinson <[email-masked]>
To: ieprep <[email-masked]>
Subject: [Ieprep] Fwd:  draft-iab-congestion-00.txt,.ps
Sender: [email-masked]

IMHO, this document is worth reading.

Ran

Begin forwarded message:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Internet Architecture Board Working 
> Group of the IETF.
>
> 	Title		: IAB Concerns Regarding Congestion Control for Voice
>                           Traffic in the Internet
> 	Author(s)	: S. Floyd, J. Kempf
> 	Filename	: draft-iab-congestion-00.txt,.ps
> 	Pages		: 25
> 	Date		: 2003-6-24
> 	
> This document discusses IAB concerns about effective end-to-end
> congestion control for best-effort voice traffic in the Internet.
> These concerns have to do with fairness, user quality, and with the
> dangers of congestion collapse on underprovisioned links in the
> Internet. The concerns are particularly relevant in light of the
> absence of a widespread QoS deployment in the Internet, and the
> likelihood that this situation will not change much in the near term.
> Feedback can be sent to the IAB mailing list at [email-masked], or to
> the editors at [email-masked] and [email-masked].  Feedback
> can also be sent to the end2end-interest mailing list [E2E].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-iab-congestion-00.txt

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

From [email-masked]  Thu Jun 26 12:24:50 2003
Subject: Re: [Ieprep] Congestion avoidance
From: Rex Buddenberg <[email-masked]>
To: RJ Atkinson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: 26 Jun 2003 09:21:17 -0700
Sender: [email-masked]

On Thu, 2003-06-26 at 06:55, RJ Atkinson wrote:

> There is operational experience in the DoD (e.g. derived from work 
> originally
> done at NRL ITD) that says that VoIP in fact is an elastic application
> -- if the right vocoders are used and sensible systems engineering 
> happens
> in the voice applications.  Those kinds of systems are in production use
> today in the operational DoD, or so I'm told by folks who should know.

The Navy's plan for ADNS evolution.  It's verbal at this point:

What they have now is a handful of different satcom channels that all
reach a router on the ship.  One of those channels has a multiplexor
that siphons off a fixed fraction of the total bandwidth and dedicates
it to voice and video apps while the rest of the channel is piped to the
ADNS router.  Behind the router are three LANs in the ship, segregated
by security and run system-high.
	The major drawback to this is that the voice and video-dedicated
bandwidth is unavailable for anything else.  The forcing function is
that the mux is obsolete and needs to be replaced anyway.

The Plan.  Migrate the voice/video applications onto the LANs and use
diff-serv to control priorities.  (read VOIP).  Then toss the mux
overboard and pipe the whole satcom channel into the router.  

The imbalances in plumbing are a bit different than most of the
scenarios imagined in IEPREP so perhaps worth describing.  For
bureaucratic silly reasons it hasn't always been this way (pier
connectivity was chronically underfunded), but it's pretty easy to
overprovision both within the ship and in the shoreside terrestrial
WAN.  For example, most new LAN installations in ships these days are
gigabit ethernet.  The radio-WAN capacities are increasing too, but
they're in the 10s of Mbit maximum territory -- several orders of
magnitude less than what we can put in the next network over on either
end.  
	So we have an hourglass bandwidth picture (a wag earlier this week
called it a sphincter).  I doubt if we will ever see a situation where
the core (meaning the radio-WAN)* portion of the network will be
overprovisioned.  If it ever happens, it will be very temporary.  

*the trend here is pretty clear -- end systems are steadily migrating
off the radio-WAN and onto the LANs next-network-over.  In Army terms,
we're not far from the day whan an infantryman will have the LAN in his
uniform and all the gadgets plug into that.  

-- 
b

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

From [email-masked]  Thu Jun 26 14:47:20 2003
From: [email-masked]
Date: Thu, 26 Jun 2003 08:43:56 EDT
Subject: Re: [Ieprep] Congestion avoidance
To: [email-masked], [email-masked]
Sender: [email-masked]

In a message dated 6/26/2003 1:07:14 AM Eastern Standard Time, 
[email-masked] writes:

[SD] Would it be possible to avoid the use of the word congestion?  It has
a particular meaning in the telephony world, and different meaning in
the Internet world.

[MAP[ Yes, a different term could be used if there is one that has the 
meaning I intend. I happen to think that "congestion" is a perfectly good word, but 
it probably needs an accurate definition for the packet-world.

[SD] 90% of today's Internet traffic depends on congestion being encountered
somewhere in the path.  Attempts in the 1980's to dynamically re-route
data traffic based on instaneous "congestion" resulted in spectacular
oscillations.  Saying you want to route around congestion gives me
bad flashbacks.

[MAP] That's an interesting statement, considering past statements by some 
that "congestion doesn't occur in the core". I think you're saying that it's 
always there, we just deal with it.

I can understand the reason for "bad flashbacks", but that doesn't resolve 
the basic need for any communications network to route around "congestion". I 
believe that non-real time applications of packet transfer could just wait until 
the packet got through. Real-time ("inelastic") applications such as voice 
can't do that.

[SD] I think you are actually refering to call blocking in traditional circuit
switched networks.  Its an issue of admission control to the circuit
switched network.  If all the circuits are in use, new calls are blocked.
Re-routing means some circuit paths are kept in reserve.  It may be
obvious, but call setup only occurs at the start of the call.

[MAP] Yes, call blocking at call setup is part of this, presuming that there 
is a Call Admission Control that allows the originating entity to decide not 
to setup the call because it knows that "congestion" exists on every possible 
path for the packet flow. This would be similar to a circuit-switched network 
that provides information to the orginiating switch that every route was 
"congested", usually done by attempting to route the call, including all the 
alternates at every switch.

But it's more than just Call Admission Control. The originating entity may 
allow the call setup to occur, thinking (or knowing) that enough capacity exists 
somewhere (or the emerency call bypasses all Call Admission Controls). But if 
the routers just send the packets down a specific, predeterimed path, 
regardless of whether that path is "congested" at the moment or not, then call setup 
will often fail. (If the call setup signaling succeeds and the calling/called 
parties are told that the call is setup and answered, but the media path isn't 
there when it's needed, that's a QoS failure, in some sense worse than if the 
call setup itself had failed.)

[SD] With a packet switched network, making a decision at the bottleneck hop
to "re-route" a packet through a different interface is almost more
work than sending packet through the preferred interface.  It also avoids
those nasty forwarding loops which occur in hop-by-hop routing when the
routing paths oscillate.

[MAP] Yes, I can imagine that making such a decision at a router to re-route 
a packet is too much work, and in fact, would be counterproductive due to 
increased packet mis-ordering at the destination. All packets of a "flow" must 
take the same path, even if that path is "congested". But the issue is 2-fold:

1. Deciding at call setup time what the packet flow path should be to avoid 
known "congestion" that exists at that moment.
2. Changing the packet flow path during a call based on a significantly 
changed "congestion" situation.

I suspect that 2. would be a problem, but 1. must be figured out. We can't 
blindly send packet flows for speech down a path that is congested. I believe 
the critical task is to figure out a way to avoid this.

Yes, "nasty" forwarding loops can be a problem, just as they were in the 
circuit-switched world which used hop-by-hop routing, where effective ways were 
standardized to prevent/detect such loops.

Mike Pierce
Artel

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

From [email-masked]  Thu Jun 26 15:46:12 2003
Date: Thu, 26 Jun 2003 15:26:42 -0400 (EDT)
From: Sean Donelan <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: [Ieprep] Congestion avoidance
Sender: [email-masked]

On Thu, 26 Jun 2003 [email-masked] wrote:
> [SD] 90% of today's Internet traffic depends on congestion being encountered
> somewhere in the path.  Attempts in the 1980's to dynamically re-route
> data traffic based on instaneous "congestion" resulted in spectacular
> oscillations.  Saying you want to route around congestion gives me
> bad flashbacks.
>
> [MAP] That's an interesting statement, considering past statements by some
> that "congestion doesn't occur in the core". I think you're saying that it's
> always there, we just deal with it.

Both statements are correct.

There is always a bottleneck.  The bottleneck is not in the core.  Paying
one or two core providers to do something different will not fix the
bottleneck.

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

From [email-masked]  Thu Jun 26 16:13:59 2003
content-class: urn:content-classes:message
Subject: RE: [Ieprep] Congestion avoidance
Date: Thu, 26 Jun 2003 15:11:35 -0500
From: "Ayyasamy, Senthilkumar  (UMKC-Student)" <[email-masked]>
To: "RJ Atkinson" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

>> [SD] 90% of today's Internet traffic depends on congestion being=20
>> encountered somewhere in the path.  Attempts in the 1980's to=20
>> dynamically re-route data traffic based on instaneous "congestion"=20
>> resulted in spectacular oscillations.  Saying you want to route=20
>> around congestion gives me bad flashbacks.
>>
>> [MAP] That's an interesting statement, considering past statements=20
>> by some that "congestion doesn't occur in the core". I think you're=20
>> saying that it's always there, we just deal with it.
>
>The phrase "somewhere in the path" includes the edge in its scope,
>and does NOT imply the core is congested.=20
http://www1.ietf.org/mail-archive/working-groups/ieprep/current/msg01576.=
html

In 1980, congestion was everywhere(not just edge). It was one of the=20
motivation for Van Jacobson's dynamic congestion control algorithms
based on thermodynamic principle. It is not the case now. But, the=20
iab-congestion draft points that too much pumping of VoIP into the
network ( with no consideration for tcp-friendliness) will lead to=20
the same state.

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

From [email-masked]  Fri Jun 27 14:59:09 2003
From: [email-masked]
Date: Fri, 27 Jun 2003 14:44:14 EDT
Subject: Re: [Ieprep] Congestion avoidance
To: [email-masked], [email-masked]
CC: [email-masked], [email-masked]
Sender: [email-masked]

--part1_19b.1734e53e.2c2dea7e_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 6/26/2003 12:23:05 PM Eastern Standard Time, 
[email-masked] writes:

>     So we have an hourglass bandwidth picture (a wag earlier this week
> called it a sphincter).  I doubt if we will ever see a situation where
> the core (meaning the radio-WAN)* portion of the network will be
> overprovisioned.  If it ever happens, it will be very temporary.  
> 
So, can we all accept Rex's example as existance proof that congestion can 
occur in the "core" and get on with discussing whether something can be done to 
deal with it? Or if you argue that the congested point he refers to is 
"access", can we agree that it is still a problem that we need to deal with?

Mike Pierce
Artel

--part1_19b.1734e53e.2c2dea7e_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 6/26/2=
003 12:23:05 PM Eastern Standard Time, [email-masked] writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"> &nbsp;&nbsp;&nbsp;So we ha=
ve an hourglass bandwidth picture (a wag earlier this week
<BR>called it a sphincter). &nbsp;I doubt if we will ever see a situation wh=
ere
<BR>the core (meaning the radio-WAN)* portion of the network will be
<BR>overprovisioned. &nbsp;If it ever happens, it will be very temporary. &n=
bsp;
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">So, can we all accept Rex's example as existance proof that=20=
congestion can occur in the "core" and get on with discussing whether someth=
ing can be done to deal with it? Or if you argue that the congested point he=
 refers to is "access", can we agree that it is still a problem that we need=
 to deal with?
<BR>
<BR>Mike Pierce
<BR>Artel
<BR>
<BR></FONT></HTML>

--part1_19b.1734e53e.2c2dea7e_boundary--

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

From [email-masked]  Fri Jun 27 16:18:09 2003
From: "King, Kimberly  S." <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Fri, 27 Jun 2003 15:47:00 -0400
Subject: [Ieprep] Agenda items for Vienna meeting
Sender: [email-masked]

Scott and I are soliciting agenda topics for the IEPREP meeting in Vienna.  

Please send an agenda request that includes a topic description, time
required, and all relevant draft titles to Scott and me.

Kimberly

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

From [email-masked]  Fri Jun 27 16:19:50 2003
Date: Fri, 27 Jun 2003 15:01:56 -0400
Subject: Re: [Ieprep] Congestion avoidance
Cc: ieprep <[email-masked]>
To: [email-masked]
From: RJ Atkinson <[email-masked]>
Sender: [email-masked]

On Friday, Jun 27, 2003, at 14:44 America/Montreal, [email-masked] 
wrote:
> Or if you argue that the congested point he refers to is "access",
> can we agree that it is still a problem that we need to deal with?

I'm don't recall anyone suggesting that access links were immune from
suggestion.  In fact, several different approaches to access congestion
(e.g. CBQ on access routers, OSPF-ECMP) have been discussed at varying 
length
on this list in the past and in meetings (e.g. Sprint discussion of CBQ
at IETF/Atlanta).  The email discussions ought to be in the archives
for this list, if there were mail delivery problems for someone at some
point in the past.

Which specific mechanism(s) are applicable to achieve one's objectives 
will
vary quite widely and will depend directly on which sort of network 
design
is deployed, the objectives, the policies, the offered load, the 
capacity,
whether the circumstance is inter-domain or intra-domain, etc.  There is
no "one size fits all" mechanism, however, as near as I can tell.  There
are any number of consultants offering advice on such matters, should
one need such advice for a particular network.

In the context of the overall Navy-wide IP network, the RF links to the
ships are important, but usually are considered to be part of the access
network.  Usually, the high-bandwidth chunks of {S,N}IPRnet (or the old 
DSnets,
or the Navy's own fibred/wired IP network segments on land) were 
considered
to be the core of the network.

Ran
[email-masked]

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

From [email-masked]  Fri Jun 27 16:35:37 2003
content-class: urn:content-classes:message
Subject: RE: [Ieprep] Congestion avoidance
Date: Fri, 27 Jun 2003 15:30:48 -0500
From: "Ayyasamy, Senthilkumar  (UMKC-Student)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> So, can we all accept Rex's example as existance proof=20
> that congestion can occur in the "core" and get on with=20
> discussing whether something can be done to deal with it?=20

It is yet another attempt to open the pandora box. You=20
obviously know the answer. Also, their seems to be=20
consensus in the mailing list(?) and at SF IETF (about=20
addressing access [1]). This issue correctly reflects=20
the views in problem-statement WG i.e. debating the=20
issues after reaching the consensus;like the site-local=20
discussion in ietf list.

[1] =
http://www1.ietf.org/mail-archive/working-groups/ieprep/current/msg01905.=
html

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

From [email-masked]  Sat Jun 28 13:54:38 2003
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Sat, 28 Jun 2003 13:50:35 -0400
Subject: [Ieprep] FYI - New T1M1 Work Item and Email List
Sender: [email-masked]

T1M1 has established an email list dedicated to the discussion of Emergency
Telecommunications Service (ETS) OAM&P topics. The list is referred to as
"T1M1ETS" and can be joined by following the instructions found at
http://www.t1.org/html/makemail.htm.

A new work item to be discussed on T1M1ETS is revising/updating ANSI
T1.202-1998, "Guidelines for Network Management of the Public Switched
Networks (PSNs) under Disaster Conditions".  For the Revision work,
Internet is being considered as one type of PSN. An initial draft (to be
used as a starting point for the Revision work) may be found at
http://www.t1.org/FileMgr/GetOneFile.taf?FileName=3M150320&NW=Y.

Ron Roman
T1M1 Vice-Chair
[email-masked]

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

From [email-masked]  Mon Jun 30 12:09:06 2003
Subject: Re: [Ieprep] Congestion avoidance
From: Rex Buddenberg <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: 30 Jun 2003 09:03:57 -0700
Sender: [email-masked]

Bad idea.

Most of the QoS control problems in radio-WANs are not susceptible to
layer 3 solutions in any event.  Unless IEPREP is interested in
reinventing media access control protocols -- layer 2 solutions and the
requirements that drive them -- don't open the can.  Corporately, IETF
does not work protocols below layer 3 so we'd clearly be exceeding
charter.  

On Fri, 2003-06-27 at 11:44, [email-masked] wrote:
> In a message dated 6/26/2003 12:23:05 PM Eastern Standard Time,
> [email-masked] writes: 
> 
> 
> >    So we have an hourglass bandwidth picture (a wag earlier this
> > week 
> > called it a sphincter).  I doubt if we will ever see a situation
> > where 
> > the core (meaning the radio-WAN)* portion of the network will be 
> > overprovisioned.  If it ever happens, it will be very temporary.   
> 
> So, can we all accept Rex's example as existance proof that congestion
> can occur in the "core" and get on with discussing whether something
> can be done to deal with it? Or if you argue that the congested point
> he refers to is "access", can we agree that it is still a problem that
> we need to deal with? 
> 
> Mike Pierce 
> Artel 
-- 
Rex Buddenberg <[email-masked]>

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