From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of King, Kimberly S.
Sent: Monday, June 02, 2003 11:52 AM
To: Ieprep (E-mail)
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of CraigDav@usa.redcross.org
Sent: Monday, June 02, 2003 11:45 PM
To: KIMBERLY.S.KING@saic.com; ieprep@ietf.org
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
craigdav@usa.redcross.org
-----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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of King, Kimberly S.
Sent: Tuesday, June 03, 2003 9:44 AM
To: 'CraigDav@usa.redcross.org'; KIMBERLY.S.KING@saic.com;
ieprep@ietf.org
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: CraigDav@usa.redcross.org [mailto:CraigDav@usa.redcross.org]
>>Sent: Monday, June 02, 2003 11:45 PM
>>To: KIMBERLY.S.KING@saic.com; ieprep@ietf.org
>>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
>>craigdav@usa.redcross.org
>>
>>
>>
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Sean Donelan
Sent: Sunday, June 15, 2003 8:16 PM
To: ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: Thursday, June 19, 2003 7:31 AM
To: IETF-Announce:
Cc: ieprep@ietf.org
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:
mailserv@ietf.org.
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: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: Thursday, June 19, 2003 7:31 AM
To: IETF-Announce:
Cc: ieprep@ietf.org
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:
mailserv@ietf.org.
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: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Mpierce1@aol.com
Sent: Monday, June 23, 2003 1:25 PM
To: ieprep@ietf.org
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: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of RJ Atkinson
Sent: Monday, June 23, 2003 1:51 PM
To: Mpierce1@aol.com
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] Congestion avoidance
On Monday, Jun 23, 2003, at 13:25 America/Montreal, Mpierce1@aol.com
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
rja@extremenetworks.com
NB: In the above, "operator" means any operator, not just an ISP.
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Ayyasamy, Senthilkumar (UMKC-Student)
Sent: Monday, June 23, 2003 3:46 PM
To: RJ Atkinson; Mpierce1@aol.com
Cc: ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Mpierce1@aol.com
Sent: Monday, June 23, 2003 4:58 PM
To: rja@extremenetworks.com
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] Congestion avoidance
In a message dated 6/23/2003 1:51:24 PM Eastern Standard Time,
rja@extremenetworks.com writes:
On Monday, Jun 23, 2003, at 13:25 America/Montreal, Mpierce1@aol.com
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
rja@extremenetworks.com
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: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of RJ Atkinson
Sent: Monday, June 23, 2003 5:46 PM
To: Mpierce1@aol.com
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] Congestion avoidance
On Monday, Jun 23, 2003, at 16:58 America/Montreal, Mpierce1@aol.com
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
rja@extremenetworks.com
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: Tuesday, June 24, 2003 7:00 AM
To: IETF-Announce:
Cc: ieprep@ietf.org
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:
mailserv@ietf.org.
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: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Ken Carlberg
Sent: Tuesday, June 24, 2003 9:36 AM
To: Mpierce1@aol.com
Cc: ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Ken Carlberg
Sent: Tuesday, June 24, 2003 9:55 AM
To: ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Tuesday, June 24, 2003 10:35 AM
To: Ken Carlberg
Cc: Mpierce1@aol.com; ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Ken Carlberg
Sent: Tuesday, June 24, 2003 10:50 AM
To: Henning Schulzrinne
Cc: Mpierce1@aol.com; ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Tuesday, June 24, 2003 10:57 AM
To: Ken Carlberg
Cc: Mpierce1@aol.com; ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Tuesday, June 24, 2003 10:57 AM
To: Ken Carlberg
Cc: Mpierce1@aol.com; ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Ken Carlberg
Sent: Tuesday, June 24, 2003 11:14 AM
To: Henning Schulzrinne
Cc: Mpierce1@aol.com; ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] 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
rja@extremenetworks.com
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] 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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Berg, Dennis
Sent: Wednesday, June 25, 2003 7:54 AM
To: 'Ken Carlberg'
Cc: ieprep@ietf.org
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:K.Carlberg@cs.ucl.ac.uk]
Sent: Tuesday, June 24, 2003 9:55 AM
To: ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
------=_NextPart_000_002A_01C33BEB.9EE27360
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
RE: [Ieprep] Framework for ETS in IP Telephony 05
-----Original Message----- From: =
ieprep-admin@ietf.org
[mailto:ieprep-admin@ietf.org] On =
Behalf Of Berg,
Dennis Sent: Wednesday, June 25, =
2003
7:54 AM To: 'Ken Carlberg' Cc: ieprep@ietf.org 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:K.Carlberg@cs.ucl.ac.uk>] Sent: Tuesday, June 24, =
2003 9:55
AM To: =
ieprep@ietf.org 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.
------=_NextPart_000_002A_01C33BEB.9EE27360--
From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Ken Carlberg
Sent: Wednesday, June 25, 2003 10:18 AM
To: Berg, Dennis
Cc: ieprep@ietf.org
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Thu Jun 26 01:02:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26088
for ; Thu, 26 Jun 2003 01:02:43 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5Q52Fl22538
for ieprep-archive@odin.ietf.org; Thu, 26 Jun 2003 01:02:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VOtj-0005rR-Dh
for ieprep-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 01:02:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26080
for ; Thu, 26 Jun 2003 01:02:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VOtg-0005YQ-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 01:02:12 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19VOta-0005YL-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 01:02:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VOtU-0005ms-Tz; Thu, 26 Jun 2003 01:02:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VOt0-0005mN-BO
for ieprep@optimus.ietf.org; Thu, 26 Jun 2003 01:01:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26032
for ; Thu, 26 Jun 2003 01:01:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VOsx-0005Y3-00
for ieprep@ietf.org; Thu, 26 Jun 2003 01:01:27 -0400
Received: from clifden.donelan.com ([199.34.53.180])
by ietf-mx with esmtp (Exim 4.12)
id 19VOsm-0005Xn-00
for ieprep@ietf.org; Thu, 26 Jun 2003 01:01:16 -0400
Received: from sean (helo=localhost)
by clifden.donelan.com with local-esmtp (Exim 3.34 #3)
id 19VOsF-0000ze-00
for ieprep@ietf.org; Thu, 26 Jun 2003 01:00:43 -0400
Date: Thu, 26 Jun 2003 01:00:43 -0400 (EDT)
From: Sean Donelan
To: ieprep@ietf.org
Subject: Re: [Ieprep] Congestion avoidance
In-Reply-To: <62.31bbdd4c.2c2891fb@aol.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
On Mon, 23 Jun 2003 Mpierce1@aol.com 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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Thu Jun 26 09:57:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25243
for ; Thu, 26 Jun 2003 09:57:42 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5QDvGg02499
for ieprep-archive@odin.ietf.org; Thu, 26 Jun 2003 09:57:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VXFT-0000eE-WE
for ieprep-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 09:57:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25214
for ; Thu, 26 Jun 2003 09:57:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VXFR-0001l4-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 09:57:13 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19VXFM-0001kx-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 09:57:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VXFF-0000XM-Fr; Thu, 26 Jun 2003 09:57:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VXEU-0000Wo-SL
for ieprep@optimus.ietf.org; Thu, 26 Jun 2003 09:56:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25187
for ; Thu, 26 Jun 2003 09:55:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VXED-0001kM-00
for ieprep@ietf.org; Thu, 26 Jun 2003 09:55:57 -0400
Received: from gnat.inet.org ([63.108.254.91])
by ietf-mx with esmtp (Exim 4.12)
id 19VXE3-0001kF-00
for ieprep@ietf.org; Thu, 26 Jun 2003 09:55:47 -0400
Received: from extremenetworks.com (unknown [10.18.3.105])
by gnat.inet.org (Postfix) with ESMTP
id 1F5E267109; Thu, 26 Jun 2003 10:22:25 -0400 (EDT)
Date: Thu, 26 Jun 2003 09:55:17 -0400
Subject: Re: [Ieprep] Congestion avoidance
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: sean@donelan.com, ieprep@ietf.org
To: Mpierce1@aol.com
From: RJ Atkinson
In-Reply-To: <1e5.bffce1c.2c2c448c@aol.com>
Message-Id:
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
On Thursday, Jun 26, 2003, at 08:43 America/Montreal, Mpierce1@aol.com
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
rja@extremenetworks.com
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Thu Jun 26 09:58:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25296
for ; Thu, 26 Jun 2003 09:58:34 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5QDw7I02773
for ieprep-archive@odin.ietf.org; Thu, 26 Jun 2003 09:58:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VXGJ-0000iK-Jx
for ieprep-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 09:58:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25266
for ; Thu, 26 Jun 2003 09:58:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VXGH-0001lc-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 09:58:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19VXGC-0001lZ-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 09:58:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VXGC-0000gF-Ul; Thu, 26 Jun 2003 09:58:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VXFV-0000eV-Vl
for ieprep@optimus.ietf.org; Thu, 26 Jun 2003 09:57:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25218
for ; Thu, 26 Jun 2003 09:57:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VXFT-0001l1-00
for ieprep@ietf.org; Thu, 26 Jun 2003 09:57:15 -0400
Received: from gnat.inet.org ([63.108.254.91])
by ietf-mx with esmtp (Exim 4.12)
id 19VXFJ-0001kw-00
for ieprep@ietf.org; Thu, 26 Jun 2003 09:57:05 -0400
Received: from extremenetworks.com (unknown [10.18.3.105])
by gnat.inet.org (Postfix) with ESMTP id ED79C67109
for ; Thu, 26 Jun 2003 10:24:05 -0400 (EDT)
Date: Thu, 26 Jun 2003 09:56:58 -0400
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: RJ Atkinson
To: ieprep
Content-Transfer-Encoding: 7bit
Message-Id: <0D75FF00-A7DE-11D7-A9C7-00039357A82A@extremenetworks.com>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [Ieprep] Fwd: draft-iab-congestion-00.txt,.ps
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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 iab@ietf.org, or to
> the editors at floyd@icir.org and kempf@docomolabs-usa.com. 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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Thu Jun 26 12:24:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07231
for ; Thu, 26 Jun 2003 12:24:50 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5QGOCE21915
for ieprep-archive@odin.ietf.org; Thu, 26 Jun 2003 12:24:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VZXg-0005hO-8v
for ieprep-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 12:24:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07198
for ; Thu, 26 Jun 2003 12:24:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VZXe-0003TO-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 12:24:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19VZXZ-0003TL-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 12:24:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VZXV-0005gU-3m; Thu, 26 Jun 2003 12:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VZWb-0005ap-7i
for ieprep@optimus.ietf.org; Thu, 26 Jun 2003 12:23:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07131
for ; Thu, 26 Jun 2003 12:23:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VZWZ-0003Sp-00
for ieprep@ietf.org; Thu, 26 Jun 2003 12:23:03 -0400
Received: from capella.nps.navy.mil ([131.120.254.83] helo=[140.32.132.66])
by ietf-mx with esmtp (Exim 4.12)
id 19VZWO-0003Sj-00
for ieprep@ietf.org; Thu, 26 Jun 2003 12:22:53 -0400
Received: from no.name.available by [140.32.132.66]
via smtpd (for [132.151.6.1]) with ESMTP; Thu, 26 Jun 2003 09:18:59 -0700
Received: from ro178-129.ro.nps.navy.mil (ro178-129.ro.nps.navy.mil [131.120.178.129])
by capella.nps.navy.mil (8.12.9/8.12.9) with ESMTP id h5QGMQ1h011208;
Thu, 26 Jun 2003 09:22:26 -0700 (PDT)
Subject: Re: [Ieprep] Congestion avoidance
From: Rex Buddenberg
To: RJ Atkinson
Cc: Mpierce1@aol.com, sean@donelan.com, ieprep@ietf.org
In-Reply-To:
References:
Content-Type: text/plain
Message-Id: <1056644477.3728.34.camel@ro178-129.ro.nps.navy.mil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5)
Date: 26 Jun 2003 09:21:17 -0700
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Thu Jun 26 14:47:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14418
for ; Thu, 26 Jun 2003 14:47:20 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5QCoxF13912
for ieprep-archive@odin.ietf.org; Thu, 26 Jun 2003 08:50:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VWDL-0003cJ-Ad
for ieprep-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 08:50:59 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21804
for ; Thu, 26 Jun 2003 08:50:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VWCP-0003Wa-1f; Thu, 26 Jun 2003 08:50:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VWBx-0003VS-KK
for ieprep@optimus.ietf.org; Thu, 26 Jun 2003 08:49:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20932
for ; Thu, 26 Jun 2003 08:49:29 -0400 (EDT)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VW9r-0000ib-00
for ieprep@ietf.org; Thu, 26 Jun 2003 08:47:23 -0400
Received: from imo-r08.mx.aol.com ([152.163.225.104])
by ietf-mx with esmtp (Exim 4.12)
id 19VW9b-0000eG-00
for ieprep@ietf.org; Thu, 26 Jun 2003 08:47:07 -0400
Received: from Mpierce1@aol.com
by imo-r08.mx.aol.com (mail_out_v36.3.) id 2.1e5.bffce1c (4552);
Thu, 26 Jun 2003 08:43:56 -0400 (EDT)
Message-ID: <1e5.bffce1c.2c2c448c@aol.com>
Date: Thu, 26 Jun 2003 08:43:56 EDT
Subject: Re: [Ieprep] Congestion avoidance
To: sean@donelan.com, ieprep@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: 6.0 for Windows XP sub 10501
Content-Transfer-Encoding: 7bit
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
In a message dated 6/26/2003 1:07:14 AM Eastern Standard Time,
sean@donelan.com 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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Thu Jun 26 15:46:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18306
for ; Thu, 26 Jun 2003 15:46:12 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5QJiAM28251
for ieprep-archive@odin.ietf.org; Thu, 26 Jun 2003 15:44:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VcfC-0007La-Du
for ieprep-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 15:44:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18226
for ; Thu, 26 Jun 2003 15:44:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VcfA-0005Kn-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 15:44:09 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19Vcf5-0005Kk-00
for ieprep-web-archive@ietf.org; Thu, 26 Jun 2003 15:44:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vcf3-0007FV-9k; Thu, 26 Jun 2003 15:44:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VcTg-00066X-LL
for ieprep@optimus.ietf.org; Thu, 26 Jun 2003 15:32:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17365
for ; Thu, 26 Jun 2003 15:27:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VcPL-0005B3-00
for ieprep@ietf.org; Thu, 26 Jun 2003 15:27:47 -0400
Received: from clifden.donelan.com ([199.34.53.180])
by ietf-mx with esmtp (Exim 4.12)
id 19VcPB-0005At-00
for ieprep@ietf.org; Thu, 26 Jun 2003 15:27:37 -0400
Received: from sean (helo=localhost)
by clifden.donelan.com with local-esmtp (Exim 3.34 #3)
id 19VcOI-0001WY-00; Thu, 26 Jun 2003 15:26:42 -0400
Date: Thu, 26 Jun 2003 15:26:42 -0400 (EDT)
From: Sean Donelan
To: Mpierce1@aol.com
cc: ieprep@ietf.org
Subject: Re: [Ieprep] Congestion avoidance
In-Reply-To: <1e5.bffce1c.2c2c448c@aol.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
On Thu, 26 Jun 2003 Mpierce1@aol.com 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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Thu Jun 26 16:13:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19576
for ; Thu, 26 Jun 2003 16:13:59 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5QKDWK07943
for ieprep-archive@odin.ietf.org; Thu, 26 Jun 2003 16:13:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vd7c-000242-3H
for ieprep-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 16:13:32 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19548
for ; Thu, 26 Jun 2003 16:13:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vd77-0001vc-0F; Thu, 26 Jun 2003 16:13:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vd6c-0001up-08
for ieprep@optimus.ietf.org; Thu, 26 Jun 2003 16:12:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19514
for ; Thu, 26 Jun 2003 16:12:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19Vd6L-0005Y7-00
for ieprep@ietf.org; Thu, 26 Jun 2003 16:12:13 -0400
Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159])
by ietf-mx with esmtp (Exim 4.12)
id 19Vd6A-0005Xz-00
for ieprep@ietf.org; Thu, 26 Jun 2003 16:12:02 -0400
Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329);
Thu, 26 Jun 2003 15:11:36 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ieprep] Congestion avoidance
Date: Thu, 26 Jun 2003 15:11:35 -0500
Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108004@KC-MAIL4.kc.umkc.edu>
Thread-Topic: [Ieprep] Congestion avoidance
Thread-Index: AcM76taLpY2Nlw3bSgGjuP5SZxb5MgAMSpUA
From: "Ayyasamy, Senthilkumar (UMKC-Student)"
To: "RJ Atkinson" ,
Cc: ,
X-OriginalArrivalTime: 26 Jun 2003 20:11:36.0019 (UTC) FILETIME=[25137230:01C33C1F]
Content-Transfer-Encoding: quoted-printable
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
>> [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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Fri Jun 27 14:59:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13450
for ; Fri, 27 Jun 2003 14:59:09 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5RIweR31773
for ieprep-archive@odin.ietf.org; Fri, 27 Jun 2003 14:58:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VyQi-0008GO-7g
for ieprep-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:58:40 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13430
for ; Fri, 27 Jun 2003 14:58:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VyQ5-0008CA-0e; Fri, 27 Jun 2003 14:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VyNy-000809-RM
for ieprep@optimus.ietf.org; Fri, 27 Jun 2003 14:57:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13313
for ; Fri, 27 Jun 2003 14:55:50 -0400 (EDT)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VyNy-0005Kq-00
for ieprep@ietf.org; Fri, 27 Jun 2003 14:55:50 -0400
Received: from imo-m03.mx.aol.com ([64.12.136.6])
by ietf-mx with esmtp (Exim 4.12)
id 19VyNj-0005Kg-00
for ieprep@ietf.org; Fri, 27 Jun 2003 14:55:35 -0400
Received: from Mpierce1@aol.com
by imo-m03.mx.aol.com (mail_out_v36_r1.1.) id i.19b.1734e53e (3940);
Fri, 27 Jun 2003 14:44:15 -0400 (EDT)
Message-ID: <19b.1734e53e.2c2dea7e@aol.com>
Date: Fri, 27 Jun 2003 14:44:14 EDT
Subject: Re: [Ieprep] Congestion avoidance
To: budden@nps.navy.mil, rja@extremenetworks.com
CC: sean@donelan.com, ieprep@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_19b.1734e53e.2c2dea7e_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
--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,
budden@nps.navy.mil 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
In a message dated 6/26/2=
003 12:23:05 PM Eastern Standard Time, budden@nps.navy.mil writes:
So we ha=
ve an hourglass bandwidth picture (a wag earlier this week
called it a sphincter). I doubt if we will ever see a situation wh=
ere
the core (meaning the radio-WAN)* portion of the network will be
overprovisioned. If it ever happens, it will be very temporary. &n=
bsp;
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?
Mike Pierce
Artel
--part1_19b.1734e53e.2c2dea7e_boundary--
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Fri Jun 27 16:18:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18804
for ; Fri, 27 Jun 2003 16:18:09 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5RKHfn26281
for ieprep-archive@odin.ietf.org; Fri, 27 Jun 2003 16:17:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VzfB-0006po-RF
for ieprep-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 16:17:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18756
for ; Fri, 27 Jun 2003 16:17:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VzfA-00063B-00
for ieprep-web-archive@ietf.org; Fri, 27 Jun 2003 16:17:40 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19Vzf4-000606-00
for ieprep-web-archive@ietf.org; Fri, 27 Jun 2003 16:17:34 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VzdZ-0006P9-Kv; Fri, 27 Jun 2003 16:16:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VzC0-0004fI-Mg
for ieprep@optimus.ietf.org; Fri, 27 Jun 2003 15:48:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17978
for ; Fri, 27 Jun 2003 15:47:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VzBz-0005nz-00
for ieprep@ietf.org; Fri, 27 Jun 2003 15:47:31 -0400
Received: from mclmx.mail.saic.com ([149.8.64.10])
by ietf-mx with esmtp (Exim 4.12)
id 19VzBo-0005nt-00
for ieprep@ietf.org; Fri, 27 Jun 2003 15:47:20 -0400
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Fri, 27 Jun 2003 15:47:02 -0400
Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11])
by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.21) with SMTP id M2003062715470204330
; Fri, 27 Jun 2003 15:47:02 -0400
Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19)
id ; Fri, 27 Jun 2003 15:49:45 -0400
Message-Id:
From: "King, Kimberly S."
To: "'ieprep@ietf.org'"
Cc: "'sob@harvard.edu'"
Date: Fri, 27 Jun 2003 15:47:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Ieprep] Agenda items for Vienna meeting
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Fri Jun 27 16:19:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19064
for ; Fri, 27 Jun 2003 16:19:50 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5RKJNp28421
for ieprep-archive@odin.ietf.org; Fri, 27 Jun 2003 16:19:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vzg2-0007Bm-Ds
for ieprep-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 16:18:34 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18857
for ; Fri, 27 Jun 2003 16:18:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19VzfW-0006rD-Ov; Fri, 27 Jun 2003 16:18:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vzef-0006gS-P0
for ieprep@optimus.ietf.org; Fri, 27 Jun 2003 16:17:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18508
for ; Fri, 27 Jun 2003 16:16:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19VzdF-0005zu-00
for ieprep@ietf.org; Fri, 27 Jun 2003 16:15:41 -0400
Received: from gnat.inet.org ([63.108.254.91])
by ietf-mx with esmtp (Exim 4.12)
id 19Vzd5-0005zq-00
for ieprep@ietf.org; Fri, 27 Jun 2003 16:15:31 -0400
Received: from extremenetworks.com (unknown [10.18.3.105])
by gnat.inet.org (Postfix) with ESMTP
id C3E5167103; Fri, 27 Jun 2003 15:29:14 -0400 (EDT)
Date: Fri, 27 Jun 2003 15:01:56 -0400
Subject: Re: [Ieprep] Congestion avoidance
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: ieprep
To: Mpierce1@aol.com
From: RJ Atkinson
In-Reply-To: <19b.1734e53e.2c2dea7e@aol.com>
Message-Id:
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
On Friday, Jun 27, 2003, at 14:44 America/Montreal, Mpierce1@aol.com
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
rja@extremenetworks.com
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Fri Jun 27 16:35:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19841
for ; Fri, 27 Jun 2003 16:35:37 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5RKZAI00586
for ieprep-archive@odin.ietf.org; Fri, 27 Jun 2003 16:35:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vzw5-00009N-UG
for ieprep-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 16:35:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19823
for ; Fri, 27 Jun 2003 16:35:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19Vzw4-0006Dv-00
for ieprep-web-archive@ietf.org; Fri, 27 Jun 2003 16:35:08 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19Vzvy-0006Ds-00
for ieprep-web-archive@ietf.org; Fri, 27 Jun 2003 16:35:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vzvx-00008b-HJ; Fri, 27 Jun 2003 16:35:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19Vzv4-00007b-UZ
for ieprep@optimus.ietf.org; Fri, 27 Jun 2003 16:34:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19749
for ; Fri, 27 Jun 2003 16:33:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19Vzun-0006D1-00
for ieprep@ietf.org; Fri, 27 Jun 2003 16:33:50 -0400
Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.159])
by ietf-mx with esmtp (Exim 4.12)
id 19Vzuc-0006Aq-00
for ieprep@ietf.org; Fri, 27 Jun 2003 16:33:39 -0400
Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329);
Fri, 27 Jun 2003 15:30:49 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ieprep] Congestion avoidance
Date: Fri, 27 Jun 2003 15:30:48 -0500
Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390BAA772C@KC-MAIL4.kc.umkc.edu>
Thread-Topic: [Ieprep] Congestion avoidance
Thread-Index: AcM83gnJNyH0LWkcSqenjoylRV7F8wAAENag
From: "Ayyasamy, Senthilkumar (UMKC-Student)"
To: , ,
Cc: ,
X-OriginalArrivalTime: 27 Jun 2003 20:30:49.0690 (UTC) FILETIME=[FF216BA0:01C33CEA]
Content-Transfer-Encoding: quoted-printable
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
> 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
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Sat Jun 28 13:54:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28283
for ; Sat, 28 Jun 2003 13:54:38 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5SHsA509122
for ieprep-archive@odin.ietf.org; Sat, 28 Jun 2003 13:54:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19WJtq-0002N3-1a
for ieprep-web-archive@optimus.ietf.org; Sat, 28 Jun 2003 13:54:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28276
for ; Sat, 28 Jun 2003 13:54:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19WJtn-0004YQ-00
for ieprep-web-archive@ietf.org; Sat, 28 Jun 2003 13:54:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12)
id 19WJti-0004YN-00
for ieprep-web-archive@ietf.org; Sat, 28 Jun 2003 13:54:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19WJth-0002MN-5o; Sat, 28 Jun 2003 13:54:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19WJt8-0002Ln-Gi
for ieprep@optimus.ietf.org; Sat, 28 Jun 2003 13:53:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28258
for ; Sat, 28 Jun 2003 13:53:09 -0400 (EDT)
From: rroman@telcordia.com
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19WJsr-0004Y2-00
for ieprep@ietf.org; Sat, 28 Jun 2003 13:53:09 -0400
Received: from dnsmx2pya.telcordia.com ([128.96.20.32])
by ietf-mx with esmtp (Exim 4.12)
id 19WJsQ-0004Xt-00
for ieprep@ietf.org; Sat, 28 Jun 2003 13:52:42 -0400
Received: from notes900.cc.telcordia.com (notes900.cc.telcordia.com [128.96.79.7])
by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id NAA18190
for ; Sat, 28 Jun 2003 13:50:30 -0400 (EDT)
To: ieprep@ietf.org
Cc: Michael.Fargano@qwest.com
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID:
Date: Sat, 28 Jun 2003 13:50:35 -0400
X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a |January 17, 2001) at
06/28/2003 01:50:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [Ieprep] FYI - New T1M1 Work Item and Email List
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
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
rroman@telcordia.com
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep
From exim@www1.ietf.org Mon Jun 30 12:09:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03264
for ; Mon, 30 Jun 2003 12:09:06 -0400 (EDT)
Received: (from exim@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h5UG8cW00494
for ieprep-archive@odin.ietf.org; Mon, 30 Jun 2003 12:08:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19X1Co-00007t-HF
for ieprep-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 12:08:38 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03231
for ; Mon, 30 Jun 2003 12:08:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19X1CD-00004x-Bw; Mon, 30 Jun 2003 12:08:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 19X1Am-0008EF-F2
for ieprep@optimus.ietf.org; Mon, 30 Jun 2003 12:07:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03164
for ; Mon, 30 Jun 2003 12:06:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 19X1Ad-0002Ev-00
for ieprep@ietf.org; Mon, 30 Jun 2003 12:06:23 -0400
Received: from capella.nps.navy.mil ([131.120.254.83] helo=[140.32.132.66])
by ietf-mx with esmtp (Exim 4.12)
id 19X1AO-0002ET-00
for ieprep@ietf.org; Mon, 30 Jun 2003 12:06:08 -0400
Received: from no.name.available by [140.32.132.66]
via smtpd (for [132.151.6.1]) with ESMTP; Mon, 30 Jun 2003 09:02:01 -0700
Received: from ro178-129.ro.nps.navy.mil (ro178-129.ro.nps.navy.mil [131.120.178.129])
by capella.nps.navy.mil (8.12.9/8.12.9) with ESMTP id h5UG5I1h017579;
Mon, 30 Jun 2003 09:05:18 -0700 (PDT)
Subject: Re: [Ieprep] Congestion avoidance
From: Rex Buddenberg
To: Mpierce1@aol.com
Cc: rja@extremenetworks.com, sean@donelan.com, ieprep@ietf.org
In-Reply-To: <19b.1734e53e.2c2dea7e@aol.com>
References: <19b.1734e53e.2c2dea7e@aol.com>
Content-Type: text/plain
Message-Id: <1056774053.3828.4.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5)
Date: 30 Jun 2003 09:03:57 -0700
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
List-Id: Internet Emergency Preparedness Working Group
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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, Mpierce1@aol.com wrote:
> In a message dated 6/26/2003 12:23:05 PM Eastern Standard Time,
> budden@nps.navy.mil 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
_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep