From exim@www1.ietf.org Wed Oct 1 09:59:31 2003 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 JAA12875 for ; Wed, 1 Oct 2003 09:59: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 1A4hVS-0001bv-GV for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 09:59:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Dx6jB006185 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 09:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hVS-0001bg-Cr for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 09:59:06 -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 JAA12858 for ; Wed, 1 Oct 2003 09:58:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hVN-0007Hh-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 09:59:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4hVM-0007He-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 09:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hVM-0001aF-K9; Wed, 01 Oct 2003 09:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hUz-0001Zo-ML for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 09:58: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 JAA12847 for ; Wed, 1 Oct 2003 09:58:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hUx-0007HH-00 for ieprep@ietf.org; Wed, 01 Oct 2003 09:58:35 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 1A4hUx-0007HE-00 for ieprep@ietf.org; Wed, 01 Oct 2003 09:58:35 -0400 Received: from extremenetworks.com (unknown [10.0.8.115]) by gnat.inet.org (Postfix) with ESMTP id 192C767104; Wed, 1 Oct 2003 10:00:41 -0400 (EDT) Date: Wed, 1 Oct 2003 09:58:24 -0400 Subject: Re: [Ieprep] The world's biggest data consumers don't think priority is such a big priority Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Donelan , ieprep@ietf.org To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.3.2.7.2.20030930183644.0267fee8@localhost> Message-Id: <53086727-F417-11D7-B968-00039357A82A@extremenetworks.com> 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 Tuesday, Sep 30, 2003, at 19:46 America/Montreal, James M. Polk wrote: > Needless to say, I completely disagree with your position and don't > rely on quotes from people I don't know (like you do apparently) to > get my information. I like first hand knowledge. James, You claimed that no one was using Ethernet for critical services without prioritisation (exact quote follows): > The US Gov and others already employ priority networks; those that > don't, > haven't moved their time critical applications over to their Ethernet > networks (yet) I have first-hand knowledge of several sites that do use Ethernet for time-critical applications and do not employ prioritisation. I work at such a site. I know of other such sites in various places around the world. I'll take any data I can get. Different data gets different weight in my analysis, depending on an assessment of its quality. Moreover, unless one is omniscient, which no one on this list is, one could not know whether 'all of those that don't use priority networks' do (or don't do) *anything*. There are far too many networks in the world for anyone to know all the pertinent details about all of them. Yet you claim to have just such knowledge. Your claim was too extreme. Had you said "many" or "some" or "few" rather than "those that don't", it might have been a lot more plausible statement. However, you didn't do so and did not clarify your meaning when questioned about it yesterday. Pity that. > I was merely reacting to the quoted person's claim that prioritization > in IP was not necessary. Nonsense. There was no comment about "prioritisation in IP" in that article. You badly misread the article at the URL provided. (For any who tuned in late, the URL is: http://news.com.com/2100-1035_3-5083779.html ) 1) The article at that URL does NOT anyplace contain the phrase "IP" or the phrase "Internet Protocol". 2) The article more than once states that AT&T is discussing an "Ethernet service". 3) Ethernet is not IP, and is in fact at a lower layer in a a conventional protocol architecture. Now, as it happens, IEEE 802.1p (now packaged in a revised 802.1d) specifies Ethernet precedence. In some ways, that IEEE mechanism is similar to the IP precedence mechanism. I know of a number of sites that use 802.1p and also a number of sites that don't use 802.1p. Now, since a private email has erroneously suggested that my employer would benefit from users not deploying QoS, I'll clarify that point. My employer quite possibly has the *best* implementation of IP ToS, DiffServ, and 802.1p available. Some of our customers enable some of those features, some do not. It would be advantageous for my employer if more folks enabled those features, because it would provide additional crisp differentiation from many of our competitors. However, on an IETF list, I express my own views about the standards topics under discussion, rather than advocating standards positions because they might advantage my employer. This might be confusing to some. It does not confuse those who've watched me in the IETF context over the years. In any event, the issues with IP prioritisation on this IETF list have been focused on the inter-domain context, where deployment of inter-domain DiffServ (or similar) mechanism creates a significant (Distributed) Denial of Service attack vector not present otherwise. If anyone has a technical approach that enables deployment of DiffServ in an inter-domain context without creating a (D)DOS attack vector, I'm sure it would be of general interest to this list (it probably deserves a new Subject: line, however :-). Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 10:13:26 2003 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 KAA14338 for ; Wed, 1 Oct 2003 10:13:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hix-0002bd-AS for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 10:13:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91ED3IE010011 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 10:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hix-0002ah-51 for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 10:13:03 -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 KAA14282 for ; Wed, 1 Oct 2003 10:12:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hiu-0007Sr-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 10:13:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4hiu-0007So-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 10:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hiv-0002Zu-PP; Wed, 01 Oct 2003 10: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 1A4hiV-0002Xq-1r for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 10:12:35 -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 KAA14208 for ; Wed, 1 Oct 2003 10:12:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hiS-0007SC-00 for ieprep@ietf.org; Wed, 01 Oct 2003 10:12:32 -0400 Received: from sonnet1.is.dyncorp.com ([131.131.11.68]) by ietf-mx with esmtp (Exim 4.12) id 1A4hiS-0007S9-00 for ieprep@ietf.org; Wed, 01 Oct 2003 10:12:32 -0400 Received: from chntex04.is.dyncorp.com (chntex04.is.dyncorp.com [131.131.133.214]) by sonnet1.is.dyncorp.com (8.12.8/8.12.8) with ESMTP id h91DK9TQ003247; Wed, 1 Oct 2003 09:24:40 -0400 (EDT) Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 09:15:57 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AB7C@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Sean Donelan'" , ieprep@ietf.org Subject: RE: [Ieprep] The world's biggest data consumers don't think prior ity is such a big priority Date: Wed, 1 Oct 2003 09:15:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , May I paraphrase? "Users with very large 'pipes' don't see the need for prioritization." That seems to be a pretty valid statement. But it says nothing about users and uses within the same organizations which do NOT have massive overcapacity pipes. -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Monday, September 29, 2003 10:30 PM To: ieprep@ietf.org Subject: [Ieprep] The world's biggest data consumers don't think priority is such a big priority "Priority" is a buzzword networking executives use to describe assigning levels of importance to network traffic. The practice is intended to ensure that a company's most important data gets through a crowded connection. But it's a different story for the health care industry and government agencies, whose notoriously large data appetites have created a market for connections 10 times the size of a typical data pipe. Since these customers haven't yet come close to stressing their connection's capacity, they have no need for expensive and hard-to-manage priority systems, AT&T Ethernet Services Director Franco Callocchia said. http://news.com.com/2100-1035_3-5083779.html _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 10:18:29 2003 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 KAA14785 for ; Wed, 1 Oct 2003 10:18: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 1A4hnq-0002im-Fe for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 10:18:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91EI6Nq010417 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 10:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hnp-0002hw-0z for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 10:18: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 KAA14768 for ; Wed, 1 Oct 2003 10:17:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hnm-0007VZ-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 10:18:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4hnm-0007VW-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 10:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hnm-0002gi-F3; Wed, 01 Oct 2003 10: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 1A4hnR-0002gD-Ew for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 10: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 KAA14719 for ; Wed, 1 Oct 2003 10:17:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hnO-0007VC-00 for ieprep@ietf.org; Wed, 01 Oct 2003 10:17:38 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 1A4hnN-0007V9-00 for ieprep@ietf.org; Wed, 01 Oct 2003 10:17:37 -0400 Received: from extremenetworks.com (unknown [10.0.8.115]) by gnat.inet.org (Postfix) with ESMTP id 2AF3D67117; Wed, 1 Oct 2003 10:19:49 -0400 (EDT) Date: Wed, 1 Oct 2003 10:17:34 -0400 Subject: Re: [Ieprep] The world's biggest data consumers don't think priority is such ... 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: <192.206be9e6.2cabaa46@aol.com> Message-Id: <0077425A-F41A-11D7-B968-00039357A82A@extremenetworks.com> 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 Earlier, Ran Atkinson wrote: >> Those folks >> further say that the US DoD JCS has *prohibited* deployment of >> prioritisation in DoD IP networks (unless a JCS waiver is obtained; >> DISA network ops folks tell me they do not have such a waiver). On Tuesday, Sep 30, 2003, at 23:55 America/Montreal, Mpierce1@aol.com wrote: > The words in the above statemet seem to have been jumbled. To correct > the word order: The JCS has prohibited further deployment of IP > networks > (for mission critical communications) until the necessary > prioritization > is possible. They do not have such a waiver. Thanks. I checked again. I am told that both statements (mine at top & yours just above) are true. It is helpful of you to clarify by adding the second statement. > I don't think that the "ops folks" are the ones to be telling you what > the requirements are for the future. Certainly there are many folks that might have an impact on the future. The "ops folks" are in a very good position to speak to the present deployments -- and my comment was a follow-up to James M Polk's claim that "The US Gov and others already employ priority networks;". Now I believe James' claim is true, at least for some USG networks, primarily since the USG is so large that it rarely has a unified position on anything and it has lots of different networks. However, I thought it worth clarifying that the JCS prohibition means that the DISA IP networks (specifically {N,S}IPRnet) are not among the USG networks that "already employ priority networks". So not all USG networks "already employ priority". To me the situation seems a bit odd, since the old DDN used the IP ToS byte as originally defined, at least in some places within the network (e.g. using Proteon routers). IMHO, in a lot of ways, the reported JCS prohibition on IP prioritisation seems unfortunate, though no doubt they have good reasons, because various mechanisms (e.g. DiffServ) can be very useful within a single administrative domain -- and uplink bandwidth is really scarce in a lot of current field operational environments (e.g. AF, IQ, ships at sea, aircraft in flight). I'll further note that I think of IP QoS as something that is just as useful for non-voice applications as for voice applications. It isn't clear to me which meaning for "communications" is intended in the statement you added, whether that is specifically voice, or is any form of communications. Perhaps that distinction isn't a key issue for this IETF WG, however. > I think they tend to think and > concern themselves with what is currently in use. You need to talk to > the standards people and those planning the future networks. Agree. I also talk with folks planning the future networks -- for example some of the many folks involved with DISA GIG-BE and other projects. And I will note that the GIG-BE RFP sought equipment that supported a variety of QoS mechanisms at different protocol layers and in different technologies. Thanks, Ran Atkinson rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 11:15:32 2003 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 LAA17485 for ; Wed, 1 Oct 2003 11:15:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ih1-0006si-Qo for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 11:15:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FF750026446 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 11:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ih1-0006sT-NK for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 11:15: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 LAA17456 for ; Wed, 1 Oct 2003 11:15:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ih0-0000TD-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 11:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4ih0-0000TA-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 11:15:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4igw-0006q8-TZ; Wed, 01 Oct 2003 11:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4igc-0006pW-Di for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 11:14:42 -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 LAA17395 for ; Wed, 1 Oct 2003 11:14:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4igb-0000SB-00 for ieprep@ietf.org; Wed, 01 Oct 2003 11:14:41 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx with esmtp (Exim 4.12) id 1A4igb-0000RE-00 for ieprep@ietf.org; Wed, 01 Oct 2003 11:14:41 -0400 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Wed, 1 Oct 2003 11:13:15 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003100111131501894 ; Wed, 01 Oct 2003 11:13:15 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2655.55) id ; Wed, 1 Oct 2003 11:13:15 -0400 Message-Id: From: "King, Kimberly S." To: "'RJ Atkinson'" , "James M. Polk" Cc: Sean Donelan , ieprep@ietf.org Subject: RE: [Ieprep] The world's biggest data consumers don't think prior ity is such a big priority Date: Wed, 1 Oct 2003 11:13:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" 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: , Ran, > Moreover, unless one is omniscient, which no one on this list > is, And how do you know that? Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 11:22:58 2003 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 LAA18413 for ; Wed, 1 Oct 2003 11:22:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ioF-0007Hm-7n for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 11:22:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FMZmb028000 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 11:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ioF-0007HX-3L for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 11:22:35 -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 LAA18362 for ; Wed, 1 Oct 2003 11:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4inj-00075T-Ej; Wed, 01 Oct 2003 11:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ind-00074x-3B for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 11:21:57 -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 LAA18265 for ; Wed, 1 Oct 2003 11:21:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4inb-0000gI-00 for ieprep@ietf.org; Wed, 01 Oct 2003 11:21:55 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 1A4inb-0000gB-00 for ieprep@ietf.org; Wed, 01 Oct 2003 11:21:55 -0400 Received: from extremenetworks.com (unknown [10.0.8.128]) by gnat.inet.org (Postfix) with ESMTP id 87AAB67124; Wed, 1 Oct 2003 11:24:03 -0400 (EDT) Date: Wed, 1 Oct 2003 11:21:47 -0400 Subject: Re: [Ieprep] The world's biggest data consumers don't think prior ity is such a big priority Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ieprep To: "King, Kimberly S." From: RJ Atkinson In-Reply-To: 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 Wednesday, Oct 1, 2003, at 11:13 America/Montreal, King, Kimberly S. wrote: >> Moreover, unless one is omniscient, which no one on this list >> is, > > And how do you know that? > > Kimberly Correct and point well taken. I retract the quote from me above, as being just as absurd as the original I griped about. Better phrasing (maybe): As far as I can tell, God isn't posting to this list yet, and in my universe only God is omniscient. :-) Thanks & Cheers, Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 11:31:59 2003 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 LAA19323 for ; Wed, 1 Oct 2003 11:31:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iwy-0008IN-0t for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 11:31:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FVaBN031881 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 11:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iwx-0008I8-Ta for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 11:31:35 -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 LAA19278 for ; Wed, 1 Oct 2003 11:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iwP-0008AG-I3; Wed, 01 Oct 2003 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iw0-000865-LJ for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 11:30: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 LAA19162 for ; Wed, 1 Oct 2003 11:30:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ivz-0000w0-00 for ieprep@ietf.org; Wed, 01 Oct 2003 11:30:35 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx with esmtp (Exim 4.12) id 1A4ivz-0000vx-00 for ieprep@ietf.org; Wed, 01 Oct 2003 11:30:35 -0400 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Wed, 1 Oct 2003 11:30:23 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003100111302205448 ; Wed, 01 Oct 2003 11:30:22 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2655.55) id ; Wed, 1 Oct 2003 11:30:22 -0400 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Cc: "'Scott Bradner ' (E-mail)" Date: Wed, 1 Oct 2003 11:30:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] Should we meet? 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: , Ah, it is that time again. The next IETF meeting is November 9-14, 2003 in Minneapolis, MN. Should IEPREP meet? What might be presented? Please send your ideas to the chairs. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 11:35:33 2003 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 LAA19665 for ; Wed, 1 Oct 2003 11:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4j0L-0008VD-8H for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 11:35:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91FZ5pK032677 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 11:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4j0L-0008Uy-4t for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 11:35: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 LAA19587 for ; Wed, 1 Oct 2003 11:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4j0J-00013b-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 11:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4j0J-00013Y-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 11:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4j0H-0008SH-SE; Wed, 01 Oct 2003 11: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 1A4izJ-0008RN-Db for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 11:34:01 -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 LAA19538 for ; Wed, 1 Oct 2003 11:33:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4izG-00012f-00 for ieprep@ietf.org; Wed, 01 Oct 2003 11:33:59 -0400 Received: from kc-msxproto4.kc.umkc.edu ([134.193.143.48]) by ietf-mx with esmtp (Exim 4.12) id 1A4izG-00012Z-00 for ieprep@ietf.org; Wed, 01 Oct 2003 11:33:58 -0400 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Wed, 1 Oct 2003 10:33:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Oct 2003 10:33:04 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390BAA7832@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] The world's biggest data consumers don't think priority is such a big priority Thread-Index: AcOIJC4mnI+PdVHdRu+6pV6/FXlsdQAA3Yqg From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "RJ Atkinson" , "James M. Polk" Cc: "Sean Donelan" , X-OriginalArrivalTime: 01 Oct 2003 15:33:47.0347 (UTC) FILETIME=[67D7B230:01C38831] Content-Transfer-Encoding: quoted-printable Subject: [Ieprep] Revisiting IP QoS: Why do we care, what have we learned? 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 just few pointers... In any case, the recently concluded SIGCOMM 03 had a workshop about = QoS. http://www.acm.org/sigcomm/sigcomm2003/workshop/ripqos/ripqos-program.htm= l I recommend, Jon's article on predictions about QoS future . QoS's Downfall: At the bottom, or not at all! J. Crowcroft, S. Hand , R. Mortier,T. Roscoe, A. Warfield=20 ACM SIGCOMM 2003 Workshop on Revisiting IP QoS Karlsruhe, Germany, August 27, 2003 = http://www.intel-research.net/Publications/Berkeley/072220031010_149.pdf the papers are available for everyone (provided as a service to all by = the members of SIGCOMM.) But, the proceedings will appear in some future = CCR.=20 probably, google for the paper titles or contact the authors. =20 >In any event, the issues with IP prioritisation on this IETF list have=20 >been focused on the inter-domain context, where deployment of = inter-domain >DiffServ (or similar) mechanism creates a significant (Distributed) >Denial of Service attack vector not present otherwise.=20 Quality of Service and Denial of Service S. Shalunov, B. Teitelbaum ACM SIGCOMM 2003 Workshop on Revisiting IP QoS Karlsruhe, Germany, August 27, 2003 http://people.internet2.edu/~ben/papers.html It doesn't provide a solution. It just talks about ben/Stanislav = experience=20 with deploying premium service(part of QBone/I2 architecture.) >If anyone has a technical approach that enables deployment of DiffServ=20 >in an inter-domain context without creating a (D)DOS attack vector, In any case, we need o proper signaling mechanism o demand pull from operators o standardization push from vendors o enough deployment experience (intra-domain) o proper Inter-domain business model. even for *standardizing* inter-domain Differv. IMO, we have not seen any of the above... Of course, we have RFC 2998 (Integrated Services=20 Operation over Diffserv Networks); but, it was never even deployed(?) I don't follow NSIS. But, seems they are more interested in QoS for=20 mobility etc.=20 As for security breaches (DoS attacks, resource hijacking etc) regarding = QoS, we simply don't have an answer. The process of avoiding DoS attacks = in diffserv is not a protocol or architecture issue; it is more of=20 implementation and operational issue. If we have enough diffserv=20 provisioned networks across the Internet, operators will enable their=20 filters accordingly. If they have proper measurement infrastructure in=20 place, a tight filter( say 1:100) will help us drill down DoS attacks. we can identify and contain DoS spread (if your clever, cut them near=20 the attack source); but, can never be avoided. IP traceback, hash=20 traceback, and itrace help to identify the source.=20 yes, RED-PD and pushback are router mechanisms to avoid DoS attacks. = But, many of the DoS packets are forged to look like a valid one. = authentication=20 mechanism (MD5 check or ipsec) are required to check for validity. In = short, we simply don't have a solution to avoid DoS attacks.=20 An interesting work will be researching on identifying QoS = vulnerabilities=20 and drawing an attack tree for executing a DoS attack. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 12:18:28 2003 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 MAA21615 for ; Wed, 1 Oct 2003 12:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4jfw-0003Ht-Uq for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 12:18:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91GI4Bp012631 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 12:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4jfw-0003He-RW for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 12:18:04 -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 MAA21596 for ; Wed, 1 Oct 2003 12:17:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4jfv-0001b8-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 12:18:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4jfv-0001b5-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 12:18:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4jft-0003Gd-5y; Wed, 01 Oct 2003 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4jf7-0003E9-7W for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 12:17:13 -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 MAA21588 for ; Wed, 1 Oct 2003 12:17:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4jf5-0001at-00 for ieprep@ietf.org; Wed, 01 Oct 2003 12:17:11 -0400 Received: from ellis.ad.nps.navy.mil ([131.120.18.61] helo=[140.32.132.66]) by ietf-mx with esmtp (Exim 4.12) id 1A4jf5-0001aq-00 for ieprep@ietf.org; Wed, 01 Oct 2003 12:17:11 -0400 Received: from no.name.available by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Wed, 1 Oct 2003 09:16:24 -0700 Received: from ro178-35.ro.nps.navy.mil ([131.120.178.35]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Oct 2003 09:17:03 -0700 Subject: Re: [Ieprep] The world's biggest data consumers don't think priority is such ... From: Rex Buddenberg To: RJ Atkinson Cc: Mpierce1@aol.com, ieprep In-Reply-To: <0077425A-F41A-11D7-B968-00039357A82A@extremenetworks.com> References: <0077425A-F41A-11D7-B968-00039357A82A@extremenetworks.com> Content-Type: text/plain Message-Id: <1065028353.3752.51.camel@ro178-35.ro.nps.navy.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Oct 2003 10:12:33 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2003 16:17:03.0842 (UTC) FILETIME=[73796420:01C38837] 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 Wed, 2003-10-01 at 07:17, RJ Atkinson wrote: > Agree. I also talk with folks planning the future networks -- > for example some of the many folks involved with DISA GIG-BE > and other projects. And I will note that the GIG-BE RFP sought > equipment that supported a variety of QoS mechanisms at different > protocol layers and in different technologies. Diffserv works essentially identically to the old JANAP 128 precedence indicator handling procedures (flash, immediate, priority, routine). That priority handling system exists today in Autodin (no, it still hasn't gone away) and in the say JANAP 128 messages are handled (at least in theory) ... which also still hasn't gone away. The distinction here is a provisioning issue. If you can overprovision the network, then we have had ample discussion here that the prioritization (e.g. diffserv) cures are worse than the disease. GIG-BE is a significant change in DISA economics (from fee-for-service to a growth capitalization) which will probably result in overprovisioning FOR THAT SEGMENT OF THE COMMS SYSTEM. But that segment is never the complete comms system -- DISA's infrastructure never touches the soldier in the field or the sailor on the ship -- those segments are always service-owned and operated. But the military comms system has bottlenecks in it that cannot be wished away by throwing money into the overprovisioning budget. For several years these bottlenecks would show up in random places because the investements are uneven. But over the long term, the bottlenecks are always in the radio-WAN. The largest pipes (which are ironically called 'High Speed Data' by the vendor) onto the typical Navy destroyer have a capacity of 64kbps. The terrestrial WAN at the commsta end of this pipe can easily be provisioned at orders of magnitude greater capacity. And the Navy has provisioned its ships afloat at orders of magnitude greater capacity (increasingly gig ethernet). I notice that the Transformational Comms System briefings have had 'make bandwidth go away as a constraint' disappear -- apparently somebody finally got a clue that the satellite capacities will always be orders of magnitude less than the terrestrial. You can cut 'military' and past 'emergency services' in the above paragraph and get the same situation. The obvious lessons here are: - overprovision when you can. Best way to do that is to up your Ao numbers by getting diverse altroutes ... you'll find yourself overprovisioning by accident. - the radio-WAN segment is one where overprovisioning is not practical -- we need some kind of control mechanism. Diffserv is one reasonable avenue, access control is another -- both are hard to do in a highly decentralized system that the internet is. How do we get there without generating a lose-lose situation? -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 12:20:31 2003 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 MAA21744 for ; Wed, 1 Oct 2003 12:20: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 1A4jhw-0003cY-26 for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 12:20:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91GK7Ip013912 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 12:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4jhv-0003cB-By for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 12:20: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 MAA21710 for ; Wed, 1 Oct 2003 12:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4jhs-0001dH-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 12:20:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4jhr-0001dE-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 12:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4jhr-0003ZO-6o; Wed, 01 Oct 2003 12:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4jhT-0003VL-V2 for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 12:19:39 -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 MAA21689 for ; Wed, 1 Oct 2003 12:19:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4jhS-0001cY-00 for ieprep@ietf.org; Wed, 01 Oct 2003 12:19:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4jhR-0001cF-00 for ieprep@ietf.org; Wed, 01 Oct 2003 12:19:38 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Oct 2003 09:24:20 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h91GJ4wn014529; Wed, 1 Oct 2003 09:19:05 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA14440; Wed, 1 Oct 2003 09:19:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20031001105543.02682500@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Oct 2003 11:19:04 -0500 To: RJ Atkinson , Mpierce1@aol.com From: "James M. Polk" Subject: Re: [Ieprep] The world's biggest data consumers don't think priority is such ... Cc: ieprep In-Reply-To: <0077425A-F41A-11D7-B968-00039357A82A@extremenetworks.com> References: <192.206be9e6.2cabaa46@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 10:17 AM 10/1/2003 -0400, RJ Atkinson wrote: >Earlier, Ran Atkinson wrote: >>>Those folks >>>further say that the US DoD JCS has *prohibited* deployment of >>>prioritisation in DoD IP networks (unless a JCS waiver is obtained; >>>DISA network ops folks tell me they do not have such a waiver). > >On Tuesday, Sep 30, 2003, at 23:55 America/Montreal, Mpierce1@aol.com wrote: > >The "ops folks" are in a very good position to speak to the present >deployments -- and my comment was a follow-up to James M Polk's >claim that "The US Gov and others already employ priority networks;". I don't know why you took the statement quoted above to mean *ALL* networks within the US Gov.... >Now I believe James' claim is true, at least for some USG networks, >primarily since the USG is so large that it rarely has a unified position >on anything and it has lots of different networks. However, I thought >it worth clarifying that the JCS prohibition means that the DISA IP >networks (specifically {N,S}IPRnet) are not among the USG networks >that "already employ priority networks". So not all USG networks >"already employ priority". Can you find any quote where I stated "all (anything)"? I didn't think so >IMHO, in a lot of ways, the reported JCS prohibition on IP prioritisation >seems unfortunate, though no doubt they have good reasons, because various >mechanisms (e.g. DiffServ) can be very useful within a single administrative >domain -- and uplink bandwidth is really scarce in a lot of current field >operational environments (e.g. AF, IQ, ships at sea, aircraft in flight). Diffserv can't preempt a session as JCS's requirements currently state needs to happen for MLPP functionality... please read *why* the prohibition was made and the waiver necessary before commenting on it. You're uninformed about this area, which is sad.... and your comments are making that fact more apparent. BTW -- I will eat one acronym I did state incorrectly. My fast fingers added "IP" to my original response to Sean's email and I knew that was not accurate just after I sent it. I know that error contributed to part of this rathole >Thanks, > >Ran Atkinson >rja@extremenetworks.com > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 13:17:26 2003 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 NAA24315 for ; Wed, 1 Oct 2003 13:17:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kb1-0007RH-MU for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 13:17:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91HH3pf028589 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 13:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kb1-0007R2-Hn for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:17:03 -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 NAA24289 for ; Wed, 1 Oct 2003 13:16:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kaz-0002Qd-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 13:17:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4kaz-0002Qa-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 13:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kaz-0007QJ-8a; Wed, 01 Oct 2003 13:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kap-0007Q6-Lx for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 13:16:51 -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 NAA24280 for ; Wed, 1 Oct 2003 13:16:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kan-0002QR-00 for ieprep@ietf.org; Wed, 01 Oct 2003 13:16:49 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 1A4kan-0002QN-00 for ieprep@ietf.org; Wed, 01 Oct 2003 13:16:49 -0400 Received: from extremenetworks.com (unknown [10.0.8.136]) by gnat.inet.org (Postfix) with ESMTP id B561B67117; Wed, 1 Oct 2003 13:19:01 -0400 (EDT) Date: Wed, 1 Oct 2003 13:15:35 -0400 Subject: Re: [Ieprep] The world's biggest data consumers don't think priority is such ... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ieprep To: "James M. Polk" From: RJ Atkinson In-Reply-To: <4.3.2.7.2.20031001105543.02682500@localhost> 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 Wednesday, Oct 1, 2003, at 12:19 America/Montreal, James M. Polk wrote: > At 10:17 AM 10/1/2003 -0400, RJ Atkinson wrote: >> Earlier, Ran Atkinson wrote: >> The "ops folks" are in a very good position to speak to the present >> deployments -- and my comment was a follow-up to James M Polk's >> claim that "The US Gov and others already employ priority networks;". > > I don't know why you took the statement quoted above to mean *ALL* > networks within the US Gov.... Your statement was ambiguous. I thought additional clarity would be useful. Clearly your mileage varies. Enjoy. >> Now I believe James' claim is true, at least for some USG networks, >> primarily since the USG is so large that it rarely has a unified >> position >> on anything and it has lots of different networks. However, I thought >> it worth clarifying that the JCS prohibition means that the DISA IP >> networks (specifically {N,S}IPRnet) are not among the USG networks >> that "already employ priority networks". So not all USG networks >> "already employ priority". > > Can you find any quote where I stated "all (anything)"? Please see above. >> IMHO, in a lot of ways, the reported JCS prohibition on IP >> prioritisation >> seems unfortunate, though no doubt they have good reasons, because >> various >> mechanisms (e.g. DiffServ) can be very useful within a single >> administrative >> domain -- and uplink bandwidth is really scarce in a lot of current >> field >> operational environments (e.g. AF, IQ, ships at sea, aircraft in >> flight). > > Diffserv can't preempt a session as JCS's requirements currently state > needs to happen for MLPP functionality... please read *why* the > prohibition was made and the waiver necessary before commenting on it. I am familiar with both. It is not at all clear that DiffServ is unable to preempt. I know of deployments of IP ToS/DiffServ where the low-precedence IP traffic is dropped and pre-empted by the high-precedence IP traffic -- because the network was configured to do just that. There are some reports by DoD components with test results that are not inconsistent with this claim. Among the keys to those successes were: - policing the markings so one avoided "precedence creep" (see postings from Rex Buddenburg et alia on this list); this is often most easily done in edge switches, though that can increase the deployment complexity. - marking network control traffic as highest priority, so that the network would not collapse due to user traffic pre-empting critical control traffic (e.g. routing protocols, bridge protocols). - ensuring that MLPP was really the policy that the network operator wanted to deploy on their network. - keeping the deployment within a single domain, so that the (D)DOS risks could be managed to level acceptable to the network operator I'd be interested to hear the specifics of what other folks think is needed beyond DiffServ (in the intra-domain deployment context). That might be a way to focus discussion in a productive way. > You're uninformed about this area, Untrue. I am informed; I've just reached different conclusions than you have, probably because I have different data than you do. The value of this list and the conversations here are the opportunities to discuss things and for everyone to collect more data and maybe even converge opinions. Calling someone else uninformed isn't terribly likely to help either put more data out or converge opinions; sigh. > and your comments are making that fact more apparent. Here we disagree, but please do enjoy your opinion. :-) > BTW -- I will eat one acronym I did state incorrectly. My fast fingers > added "IP" to my original response to Sean's email and I knew that was > not accurate just after I sent it. I know that error contributed to > part of this rathole Thanks. Ran Atkinson rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 1 13:27:26 2003 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 NAA24677 for ; Wed, 1 Oct 2003 13:27:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kki-0007zV-4O for ieprep-archive@odin.ietf.org; Wed, 01 Oct 2003 13:27:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91HR4vs030684 for ieprep-archive@odin.ietf.org; Wed, 1 Oct 2003 13:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kkh-0007yp-Tn for ieprep-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:27:03 -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 NAA24653 for ; Wed, 1 Oct 2003 13:26:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kkf-0002WJ-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 13:27:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4kkf-0002WG-00 for ieprep-web-archive@ietf.org; Wed, 01 Oct 2003 13:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kkf-0007y7-7v; Wed, 01 Oct 2003 13:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kkU-0007xq-Rf for ieprep@optimus.ietf.org; Wed, 01 Oct 2003 13:26: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 NAA24647 for ; Wed, 1 Oct 2003 13:26:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kkS-0002W7-00 for ieprep@ietf.org; Wed, 01 Oct 2003 13:26:48 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 1A4kkS-0002W3-00 for ieprep@ietf.org; Wed, 01 Oct 2003 13:26:48 -0400 Received: from extremenetworks.com (unknown [10.0.8.136]) by gnat.inet.org (Postfix) with ESMTP id 69FC467117; Wed, 1 Oct 2003 13:29:00 -0400 (EDT) Date: Wed, 1 Oct 2003 13:26:44 -0400 Subject: Re: [Ieprep] Military comms Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ieprep To: Rex Buddenberg From: RJ Atkinson In-Reply-To: <1065028353.3752.51.camel@ro178-35.ro.nps.navy.mil> Message-Id: <6D87D3A8-F434-11D7-9DB1-00039357A82A@extremenetworks.com> 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 Wednesday, Oct 1, 2003, at 13:12 America/Montreal, Rex Buddenberg wrote: > But that segment is never the complete comms system -- DISA's > infrastructure never touches the soldier in the field or the > sailor on the ship -- those segments are always service-owned and > operated. Agree. However, all of the segments (DISA + service-specific + other DoD) can be considered to be a single administrative domain for policy purposes, since a common policy can be decided upon by SECDEF (or designee like ASDNII) and then deployed department-wide. > But the military comms system has bottlenecks in it that cannot be > wished away by throwing money into the overprovisioning budget. (also links that the DoD chooses not to spend money on; both reasons drive the ongoing existence of bottlenecks :-) > But over the long term, the bottlenecks are always in the radio-WAN. Yes. > The largest pipes (which are ironically > called 'High Speed Data' by the vendor) onto the typical Navy destroyer > have a capacity of 64kbps. The terrestrial WAN at the commsta end of > this pipe can easily be provisioned at orders of magnitude greater > capacity. And the Navy has provisioned its ships afloat at orders of > magnitude greater capacity (increasingly gig ethernet). Yes. > I notice that the Transformational Comms System briefings have had > 'make bandwidth go away as a constraint' disappear -- apparently > somebody finally got a clue that the satellite capacities will always > be > orders of magnitude less than the terrestrial. Right. > The obvious lessons here are: > - overprovision when you can. Best way to do that is to up your Ao > numbers by getting diverse altroutes ... you'll find yourself > overprovisioning by accident. > - the radio-WAN segment is one where overprovisioning is not practical s/not practical/often not practical/ > -- we need some kind of control mechanism. Diffserv is one reasonable > avenue, access control is another -- both are hard to do in a highly > decentralized system that the internet is. How do we get there without > generating a lose-lose situation? Good questions. I think the answers are a lot easier intra-domain than inter-domain. Intra-domain, one can deploy both DiffServ (or IP ToS with JANAP-like markings) (optionally also link-layer precedence, such as 802.1p) and also access controls. This requires non-trivial effort in designing the right controls/markings, getting the relevant network kit configured appropriately, and getting the network monitoring systems in place to monitor the network appropriately. I've seen this done, so I believe it is do-able. I'd be interested to know what specific capabilities folks think we need beyond what we have in hand (e.g. DiffServ, IP ToS, 802.1p). Thanks, Ran Atkinson rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Oct 3 15:24:41 2003 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 PAA22799 for ; Fri, 3 Oct 2003 15:24:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VX5-0007E3-N4 for ieprep-archive@odin.ietf.org; Fri, 03 Oct 2003 15:24:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93JO7wa027776 for ieprep-archive@odin.ietf.org; Fri, 3 Oct 2003 15:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VX5-0007Dv-FZ for ieprep-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 15:24: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 PAA22756 for ; Fri, 3 Oct 2003 15:23:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VX4-0005FY-00 for ieprep-web-archive@ietf.org; Fri, 03 Oct 2003 15:24:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5VX3-0005FU-00 for ieprep-web-archive@ietf.org; Fri, 03 Oct 2003 15: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 1A5VWy-0007CT-Tc; Fri, 03 Oct 2003 15:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VWm-0007C9-0r for ieprep@optimus.ietf.org; Fri, 03 Oct 2003 15:23:48 -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 PAA22737 for ; Fri, 3 Oct 2003 15:23:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VWk-0005FA-00 for ieprep@ietf.org; Fri, 03 Oct 2003 15:23:46 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1A5VWk-0005Eo-00 for ieprep@ietf.org; Fri, 03 Oct 2003 15:23:46 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA18204; Fri, 3 Oct 2003 15:23:13 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13483; Fri, 3 Oct 2003 15:23:15 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Oct 2003 15:23:14 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5F68@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'RJ Atkinson'" , Rex Buddenberg Cc: ieprep Subject: RE: [Ieprep] Military comms Date: Fri, 3 Oct 2003 15:23:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Depends on what your goal is. If you are on a VoIP call, and you have lower-than-someone-else priority on bandwidth, then the network may do what is intended under congestion (not give you much bandwidth), but that is not necessarily all you want. What you might want is call admission control - if the call goes through, you get "good" service. If the network can't give you good service, you might prefer to be told up front in the form of a "busy" indication. Brian > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Wednesday, October 01, 2003 1:27 PM > To: Rex Buddenberg > Cc: ieprep > Subject: Re: [Ieprep] Military comms > > > > On Wednesday, Oct 1, 2003, at 13:12 America/Montreal, Rex Buddenberg > wrote: > > But that segment is never the complete comms system -- DISA's > > infrastructure never touches the soldier in the field or the > > sailor on the ship -- those segments are always service-owned and > > operated. > > Agree. However, all of the segments (DISA + service-specific > + other DoD) can be considered to be a single administrative domain > for policy purposes, since a common policy can be decided upon > by SECDEF (or designee like ASDNII) and then deployed department-wide. > > > But the military comms system has bottlenecks in it that cannot be > > wished away by throwing money into the overprovisioning budget. > > (also links that the DoD chooses not to spend money on; both reasons > drive the ongoing existence of bottlenecks :-) > > > But over the long term, the bottlenecks are always in the radio-WAN. > > Yes. > > > The largest pipes (which are ironically > > called 'High Speed Data' by the vendor) onto the typical > Navy destroyer > > have a capacity of 64kbps. The terrestrial WAN at the > commsta end of > > this pipe can easily be provisioned at orders of magnitude greater > > capacity. And the Navy has provisioned its ships afloat at > orders of > > magnitude greater capacity (increasingly gig ethernet). > > Yes. > > > I notice that the Transformational Comms System > briefings have had > > 'make bandwidth go away as a constraint' disappear -- apparently > > somebody finally got a clue that the satellite capacities > will always > > be > > orders of magnitude less than the terrestrial. > > Right. > > > The obvious lessons here are: > > - overprovision when you can. Best way to do that is > to up your Ao > > numbers by getting diverse altroutes ... you'll find yourself > > overprovisioning by accident. > > - the radio-WAN segment is one where overprovisioning > is not practical > > s/not practical/often not practical/ > > > -- we need some kind of control mechanism. Diffserv is one > reasonable > > avenue, access control is another -- both are hard to do in a highly > > decentralized system that the internet is. How do we get > there without > > generating a lose-lose situation? > > Good questions. > > I think the answers are a lot easier intra-domain than inter-domain. > > Intra-domain, one can deploy both DiffServ (or IP ToS with JANAP-like > markings) (optionally also link-layer precedence, such as 802.1p) and > also access controls. This requires non-trivial effort in > designing the > right controls/markings, getting the relevant network kit configured > appropriately, and getting the network monitoring systems in place > to monitor the network appropriately. I've seen this done, > so I believe it is do-able. > > I'd be interested to know what specific capabilities folks think we > need beyond what we have in hand (e.g. DiffServ, IP ToS, 802.1p). > > Thanks, > > Ran Atkinson > rja@extremenetworks.com > > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Oct 6 09:08:35 2003 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 JAA28566 for ; Mon, 6 Oct 2003 09: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 1A6V5v-00053t-GE for ieprep-archive@odin.ietf.org; Mon, 06 Oct 2003 09:08:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96D8Big019451 for ieprep-archive@odin.ietf.org; Mon, 6 Oct 2003 09:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6V5v-00053e-A8 for ieprep-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 09:08:11 -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 JAA28544 for ; Mon, 6 Oct 2003 09:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6V5t-0004ui-00 for ieprep-web-archive@ietf.org; Mon, 06 Oct 2003 09:08:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6V5t-0004ue-00 for ieprep-web-archive@ietf.org; Mon, 06 Oct 2003 09:08:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6V5l-00051U-4J; Mon, 06 Oct 2003 09: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 1A6V54-0004p3-KJ for ieprep@optimus.ietf.org; Mon, 06 Oct 2003 09:07:18 -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 JAA28466 for ; Mon, 6 Oct 2003 09:07:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6V53-0004tm-00 for ieprep@ietf.org; Mon, 06 Oct 2003 09:07:17 -0400 Received: from gnat.inet.org ([63.108.254.91]) by ietf-mx with esmtp (Exim 4.12) id 1A6V51-0004tf-00 for ieprep@ietf.org; Mon, 06 Oct 2003 09:07:16 -0400 Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 049F967116; Mon, 6 Oct 2003 09:10:11 -0400 (EDT) Date: Mon, 6 Oct 2003 09:07:02 -0400 Subject: Re: [Ieprep] Military comms Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ieprep To: "Rosen, Brian" From: RJ Atkinson In-Reply-To: <313680C9A886D511A06000204840E1CF070B5F68@whq-msgusr-02.pit.comms.marconi.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, Oct 3, 2003, at 15:23 America/Montreal, Rosen, Brian wrote: > Depends on what your goal is. > > If you are on a VoIP call, and you have lower-than-someone-else > priority on bandwidth, then the network may do what is intended > under congestion (not give you much bandwidth), but that is not > necessarily all you want. What you might want is call admission > control - if the call goes through, you get "good" service. Thanks for the followup. I guess I was unclear. Sorry. I would call that one form of access control, so that is not inconsistent with my original statement. To try to be more clear, I meant "access controls" (quoted text at bottom) in a very broad sense, not some narrow sense. As you say, which set of access controls is useful/needed varies with what one's goal might be. Inter-Domain remains quite ugly in any event, because one's own desired policy might not be identical with some other operator's deployed policy. (Again, "operator" is broadly defined here to mean any operator, not just an ISP.) > If the network can't give you good service, you might prefer to be > told up front in the form of a "busy" indication. I'm sure that is sometimes true. In the particular case, the deployed AutoVON ("DSN" to some) does pre-empt (i.e. terminate if already in progress) lower precedence calls if necessary, when the capacity is needed for a higher precedence call. As far as I know, this has been the AutoVON practice (at least outside CONUS) since at least the early 1970s, quite possibly for longer than that. > Brian > >> -----Original Message----- >> From: RJ Atkinson [mailto:rja@extremenetworks.com] >> Sent: Wednesday, October 01, 2003 1:27 PM >> To: Rex Buddenberg >> Cc: ieprep >> Subject: Re: [Ieprep] Military comms >> >> ...[stuff deleted here]... >> >> Intra-domain, one can deploy both DiffServ (or IP ToS with JANAP-like >> markings) (optionally also link-layer precedence, such as 802.1p) and >> also access controls. This requires non-trivial effort in >> designing the right controls/markings, getting the relevant network >> kit configured appropriately, and getting the network monitoring >> systems >> in place to monitor the network appropriately. I've seen this done, >> so I believe it is do-able. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Oct 7 11:05:30 2003 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 LAA05681 for ; Tue, 7 Oct 2003 11:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tOg-0005dT-Nm for ieprep-archive@odin.ietf.org; Tue, 07 Oct 2003 11:05:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97F5AW0021659 for ieprep-archive@odin.ietf.org; Tue, 7 Oct 2003 11:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tOf-0005dG-Li for ieprep-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 11:05: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 LAA05610 for ; Tue, 7 Oct 2003 11:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6tOc-0006e6-00 for ieprep-web-archive@ietf.org; Tue, 07 Oct 2003 11:05:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6tOc-0006e2-00 for ieprep-web-archive@ietf.org; Tue, 07 Oct 2003 11:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tOY-0005Zy-Ie; Tue, 07 Oct 2003 11:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tOO-0005YU-6c for ieprep@optimus.ietf.org; Tue, 07 Oct 2003 11:04:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05563; Tue, 7 Oct 2003 11:04:40 -0400 (EDT) Message-Id: <200310071504.LAA05563@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 Oct 2003 11:04:40 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt 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: , --NextPart 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-06.txt Pages : 27 Date : 2003-10-7 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-06.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-06.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-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-7111012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-7111012.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 8 08:33:31 2003 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 IAA11717 for ; Wed, 8 Oct 2003 08:33:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DV6-00027W-VD for ieprep-archive@odin.ietf.org; Wed, 08 Oct 2003 08:33:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98CX8N8008144 for ieprep-archive@odin.ietf.org; Wed, 8 Oct 2003 08:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DV6-00027H-Pu for ieprep-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 08:33:08 -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 IAA11706 for ; Wed, 8 Oct 2003 08:32:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DV5-0004Fa-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 08:33:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7DV5-0004FX-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 08:33:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DUz-00025m-Bu; Wed, 08 Oct 2003 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DU7-000232-An for ieprep@optimus.ietf.org; Wed, 08 Oct 2003 08:32: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 IAA11691 for ; Wed, 8 Oct 2003 08:31:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DU6-0004Eu-00 for ieprep@ietf.org; Wed, 08 Oct 2003 08:32:06 -0400 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1A7DU5-0004E7-00 for ieprep@ietf.org; Wed, 08 Oct 2003 08:32:05 -0400 Received: (qmail 21872 invoked from network); 8 Oct 2003 12:31:34 -0000 Received: from pool-141-157-11-220.balt.east.verizon.net (HELO albers) (141.157.11.220) by uk.simply.net with SMTP; 8 Oct 2003 12:31:34 -0000 From: "Ken Carlberg" To: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Date: Wed, 8 Oct 2003 08:31:18 -0400 Message-ID: <001f01c38d98$13a54710$7301a8c0@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200310071504.LAA05563@ietf.org> 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 Barring objections from the group, I'd like to request that the chairs announce a last call for this Telephony Framework draft. I've purposely delayed this request so that the requirements drafts could be advanced up the standardization food chain. With that process winding down, I'd like to finish off the Framework draft. Thanks, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 8 11:05:29 2003 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 LAA20816 for ; Wed, 8 Oct 2003 11:05: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 1A7FsD-0002yg-3N for ieprep-archive@odin.ietf.org; Wed, 08 Oct 2003 11:05:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98F59Sr011440 for ieprep-archive@odin.ietf.org; Wed, 8 Oct 2003 11:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FsC-0002yR-VG for ieprep-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 11:05:08 -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 LAA20771 for ; Wed, 8 Oct 2003 11:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7FsA-0006dD-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 11:05:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7FsA-0006dA-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 11:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Fs5-0002ww-5l; Wed, 08 Oct 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Fry-0002wU-N3 for ieprep@optimus.ietf.org; Wed, 08 Oct 2003 11:04:54 -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 LAA20748 for ; Wed, 8 Oct 2003 11:04:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Frv-0006cd-00 for ieprep@ietf.org; Wed, 08 Oct 2003 11:04:51 -0400 Received: from sonnet1.is.dyncorp.com ([131.131.11.68]) by ietf-mx with esmtp (Exim 4.12) id 1A7Frv-0006cR-00 for ieprep@ietf.org; Wed, 08 Oct 2003 11:04:51 -0400 Received: from chntex04.is.dyncorp.com (chntex04.is.dyncorp.com [131.131.133.214]) by sonnet1.is.dyncorp.com (8.12.8/8.12.8) with ESMTP id h98F4uTO012357; Wed, 8 Oct 2003 11:04:56 -0400 (EDT) Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 11:02:48 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AB96@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Ken Carlberg'" , ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Date: Wed, 8 Oct 2003 11:02:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Comments on draft-ietf-ieprep-framework-06.txt Comments on substance first, then editorial. Substance 1.2 third para I have always understood that jitter was more important than delay for VoIP, but you do not mention it. 1.2 fourth para This is stated as the opposite of what I have always understood. I have always seen it that VoIP applications can tolerate a higher drop rate, and even a moderate delay, as long as jitter is very small. Conversely elastic applications such as email and web browsing can tolerate high jitter and delay, but need a low drop rate (because in email and web browsing the dropped packets need to be retransmitted, but in VoIP, if they are dropped you forget about them). Even a drop rate of "5%" is considered a very high drop rate in a (data) world where the starting point for drop rates is 10 to the minus 6. 4.4 first para The statement that "the user authenticates himself... using a PIN" is true for GETS but not for WPS, nor for line authentication, nor for other related programs, and therefore not for "PSTN" in general. If you said "the user authenticates himself as usual to the network" it would be a valid statement. Editorial Section 1 First para " Best effort ...infers..." should be "Best effort ... implies ..." ("infers" = "deduces") Third para Do you mean "stub domain" or "single domain"? The statement would seem to also apply to a single domain "bridging" scenario. 1.2 first para It would be clearer if you said "... though not necessarily Voice over IP which is not IP telephony" , instead of just "... though not necessarily Voice over IP Section 3 Last line Should be "violate", not "violet". Section 4.1.5 MEGACO (RFC 3015) has been "obsoleted" by Gateway Control Protocol Version 1 (RFC 3525) The statement that priority 0 is the lowest and priority 15 is the highest is in 3525 but not in 3015. 4.4 last para says "IEPS" rather than "ETS". Is this intentional? 4.5 last para "meetings" should be "meeting" Section 5, text after figure 1 Do you mean "Grade of Service" (= blocking probability based on Erlang's formulae) or "Quality of Service" (= jitter, delay, drop rate)? Janet -----Original Message----- From: Ken Carlberg [mailto:carlberg@g11.org.uk] Sent: Wednesday, October 08, 2003 8:31 AM To: ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Barring objections from the group, I'd like to request that the chairs announce a last call for this Telephony Framework draft. I've purposely delayed this request so that the requirements drafts could be advanced up the standardization food chain. With that process winding down, I'd like to finish off the Framework draft. Thanks, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 8 14:28:26 2003 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 OAA01421 for ; Wed, 8 Oct 2003 14:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7J2b-0000HI-KH for ieprep-archive@odin.ietf.org; Wed, 08 Oct 2003 14:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98IS5no001062 for ieprep-archive@odin.ietf.org; Wed, 8 Oct 2003 14:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7J2b-0000H3-Ek for ieprep-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 14:28: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 OAA01414 for ; Wed, 8 Oct 2003 14:27:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7J2Y-0002RX-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 14:28:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7J2Y-0002RQ-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 14:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7J2X-0000FG-2f; Wed, 08 Oct 2003 14:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7J2U-0000Es-Bi for ieprep@optimus.ietf.org; Wed, 08 Oct 2003 14:27:58 -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 OAA01403 for ; Wed, 8 Oct 2003 14:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7J2R-0002RA-00 for ieprep@ietf.org; Wed, 08 Oct 2003 14:27:55 -0400 Received: from mtassp3.ncr.disa.mil ([164.117.82.26] helo=pfwssp1.ncr.disa.mil) by ietf-mx with esmtp (Exim 4.12) id 1A7J2Q-0002Qj-00 for ieprep@ietf.org; Wed, 08 Oct 2003 14:27:55 -0400 Received: from mtassp3.ncr.disa.mil by pfwssp1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 8 Oct 2003 14:26:11 -0400 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id <4P595BJD>; Wed, 8 Oct 2003 14:27:23 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF5065@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'ieprep@ietf.org'" Date: Wed, 8 Oct 2003 14:27:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Ieprep] IP Transport of WPS traffic 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: , Hi all, I have the following issue I like to discuss with all of you. Wireless Priority Service currently allows authorized users to obtain the next available radio resources (access and egress) on a priority basis. There are five levels defined by the FCC Regulation and Order as follows: Level 1 - Executive Leadership and Policy Makers Level 2 - Disaster Response/Military Command and Control Level 3 - Public Health, Safety, and Law Enforcement Command Level 4 - Public Service/Utilities and Public Welfare Level 5 - Disaster Recovery WPS does not require any preemption feature. It will not disrupt any previously established calls and/or sessions. It allows WPS users wait in the queue for radio access channels until the previous calls are completed before they can make WPS calls . WPS is now available on one of the GSM-based networks. It is not yet available on any CDMA-based networks. Below is scenario where IP networks are involved in the WPS calls. ----------------- --------------------------- ---------------------- - - - - - - - - - - - - - WPS ----------------- IP ----------------- WPS - - - - - - (GSM/ - - (GSM/ - - - - CDMA) - - CDMA) - - - - - ----------------- --------------------------- ----------------------- Assumption: No congestion is in the IP backbone for now. Need: There is a need for WPS priority markers associated with WPS calls originated in one wireless network to traverse IP networks and get into another wireless network. Requirement: It is required that IP network must have capability to carry markers associated with WPS calls across its backbone network so that, for the lack of better words, WPS can have end-to-end priority. Since the IEPREP WG is chartered to discuss requirements related to emergency preparedness, I would like to share this requirement with the group. Regards, An Nguyen _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 8 14:53:23 2003 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 OAA02624 for ; Wed, 8 Oct 2003 14:53:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JQl-0001rp-0b for ieprep-archive@odin.ietf.org; Wed, 08 Oct 2003 14:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Ir2Bu007171 for ieprep-archive@odin.ietf.org; Wed, 8 Oct 2003 14:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JQk-0001ra-Tc for ieprep-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 14:53:02 -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 OAA02601 for ; Wed, 8 Oct 2003 14:52:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JQi-0002ly-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 14:53:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7JQh-0002lv-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 14:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JQj-0001qG-Da; Wed, 08 Oct 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JQB-0001pj-1S for ieprep@optimus.ietf.org; Wed, 08 Oct 2003 14:52:27 -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 OAA02523 for ; Wed, 8 Oct 2003 14:52:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JQ8-0002l7-00 for ieprep@ietf.org; Wed, 08 Oct 2003 14:52:24 -0400 Received: from mtassp3.ncr.disa.mil ([164.117.82.26] helo=pfwssp1.ncr.disa.mil) by ietf-mx with esmtp (Exim 4.12) id 1A7JQ7-0002kf-00 for ieprep@ietf.org; Wed, 08 Oct 2003 14:52:23 -0400 Received: from mtassp3.ncr.disa.mil by pfwssp1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 8 Oct 2003 14:50:40 -0400 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id <4P595C3L>; Wed, 8 Oct 2003 14:51:56 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF5067@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'ieprep@ietf.org'" Date: Wed, 8 Oct 2003 14:51:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Ieprep] IP Transport of WPS traffic 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: , Sorry for the messed-up diagram in the previous email due to the limited number of characters per line in the SMTP format! I am sending a fixed-up one. An -----Original Message----- From: Nguyen, An [mailto:nguyena@ncs.gov] Sent: Wednesday, October 08, 2003 2:27 PM To: 'ieprep@ietf.org' Subject: [Ieprep] IP Transport of WPS traffic Hi all, I have the following issue I like to discuss with all of you. Wireless Priority Service currently allows authorized users to obtain the next available radio resources (access and egress) on a priority basis. There are five levels defined by the FCC Regulation and Order as follows: Level 1 - Executive Leadership and Policy Makers Level 2 - Disaster Response/Military Command and Control Level 3 - Public Health, Safety, and Law Enforcement Command Level 4 - Public Service/Utilities and Public Welfare Level 5 - Disaster Recovery WPS does not require any preemption feature. It will not disrupt any previously established calls and/or sessions. It allows WPS users wait in the queue for radio access channels until the previous calls are completed before they can make WPS calls . WPS is now available on one of the GSM-based networks. It is not yet available on any CDMA-based networks. Below is scenario where IP networks are involved in the WPS calls. -------------- -------------- --------------- - - - - - - - - - - - - - - - - - - - WPS ----------- IP ------------ WPS - - (GSM/ - - - - (GSM/ - - CDMA) - - - - CDMA) - - - - - - - -------------- -------------- --------------- Assumption: No congestion is in the IP backbone for now. Need: There is a need for WPS priority markers associated with WPS calls originated in one wireless network to traverse IP networks and get into another wireless network. Requirement: It is required that IP network must have capability to carry markers associated with WPS calls across its backbone network so that, for the lack of better words, WPS can have end-to-end priority. Since the IEPREP WG is chartered to discuss requirements related to emergency preparedness, I would like to share this requirement with the group. Regards, An Nguyen _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 8 15:20:29 2003 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 PAA04964 for ; Wed, 8 Oct 2003 15:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jqw-0004Fy-Tk for ieprep-archive@odin.ietf.org; Wed, 08 Oct 2003 15:20:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98JK6dB016355 for ieprep-archive@odin.ietf.org; Wed, 8 Oct 2003 15:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jqw-0004Fi-AI for ieprep-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:20:06 -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 PAA04936 for ; Wed, 8 Oct 2003 15:19:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jqu-000399-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 15:20:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Jqu-000396-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 15:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jqu-0004F6-7q; Wed, 08 Oct 2003 15:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JqD-0004Db-QE for ieprep@optimus.ietf.org; Wed, 08 Oct 2003 15:19:21 -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 PAA04864 for ; Wed, 8 Oct 2003 15:19:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JqB-00038a-00 for ieprep@ietf.org; Wed, 08 Oct 2003 15:19:19 -0400 Received: from sonnet1.is.dyncorp.com ([131.131.11.68]) by ietf-mx with esmtp (Exim 4.12) id 1A7JqB-00038O-00 for ieprep@ietf.org; Wed, 08 Oct 2003 15:19:19 -0400 Received: from chntex04.is.dyncorp.com (chntex04.is.dyncorp.com [131.131.133.214]) by sonnet1.is.dyncorp.com (8.12.8/8.12.8) with ESMTP id h98JIvTO022800; Wed, 8 Oct 2003 15:19:28 -0400 (EDT) Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:16:49 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AB9C@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Nguyen, An'" , "'ieprep@ietf.org'" Subject: RE: [Ieprep] IP Transport of WPS traffic Date: Wed, 8 Oct 2003 15:16:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , An, Thanks for the fixed diagram. Are you considering the case of an IP backbone WITHIN a single WPS-Supporting Wireless Service Provider, or are you considering the case of an IP based long distance provider connecting two distinct WPS-Supporting Wireless Service Providers? Or both? Your "need" seems to address the second case, but I think the first case needs to be addressed too. Are you assuming that the IP network is a "private" IP network, or are you assuming it to be the "Big I" Internet? There are similar needs for the "GETS to WPS" and "WPS to GETS" case, if there is an IP network between the WPS-Supporting Wireless Service Provider and the GETS-Supporting LEC or IXC. Since you are assuming no congestion in the IP part, the focus is on getting the relevant ISUP parameters ((CPC parameter = HPC) for GETS, and ((CPC parameter = HPC) PLUS (Precedence parameter Precedence Level = 0 through 4, (based on calling party's Service User Priority), and MLPP Service Domain = NCS Wireless Priority Service-1 through NCS Wireless Priority Service-5 (again based on calling party's Service User Priority))) from the originating WPS-Supporting Wireless Service Provider to the terminating WPS-Supporting Wireless Service Provider. Thanks for bringing this up. Janet -----Original Message----- From: Nguyen, An [mailto:nguyena@ncs.gov] Sent: Wednesday, October 08, 2003 2:52 PM To: 'ieprep@ietf.org' Subject: [Ieprep] IP Transport of WPS traffic Sorry for the messed-up diagram in the previous email due to the limited number of characters per line in the SMTP format! I am sending a fixed-up one. An -----Original Message----- From: Nguyen, An [mailto:nguyena@ncs.gov] Sent: Wednesday, October 08, 2003 2:27 PM To: 'ieprep@ietf.org' Subject: [Ieprep] IP Transport of WPS traffic Hi all, I have the following issue I like to discuss with all of you. Wireless Priority Service currently allows authorized users to obtain the next available radio resources (access and egress) on a priority basis. There are five levels defined by the FCC Regulation and Order as follows: Level 1 - Executive Leadership and Policy Makers Level 2 - Disaster Response/Military Command and Control Level 3 - Public Health, Safety, and Law Enforcement Command Level 4 - Public Service/Utilities and Public Welfare Level 5 - Disaster Recovery WPS does not require any preemption feature. It will not disrupt any previously established calls and/or sessions. It allows WPS users wait in the queue for radio access channels until the previous calls are completed before they can make WPS calls . WPS is now available on one of the GSM-based networks. It is not yet available on any CDMA-based networks. Below is scenario where IP networks are involved in the WPS calls. -------------- -------------- --------------- - - - - - - - - - - - - - - - - - - - WPS ----------- IP ------------ WPS - - (GSM/ - - - - (GSM/ - - CDMA) - - - - CDMA) - - - - - - - -------------- -------------- --------------- Assumption: No congestion is in the IP backbone for now. Need: There is a need for WPS priority markers associated with WPS calls originated in one wireless network to traverse IP networks and get into another wireless network. Requirement: It is required that IP network must have capability to carry markers associated with WPS calls across its backbone network so that, for the lack of better words, WPS can have end-to-end priority. Since the IEPREP WG is chartered to discuss requirements related to emergency preparedness, I would like to share this requirement with the group. Regards, An Nguyen _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 8 18:54:29 2003 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 SAA13738 for ; Wed, 8 Oct 2003 18:54:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NC5-0007p2-S6 for ieprep-archive@odin.ietf.org; Wed, 08 Oct 2003 18:54:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Ms906030062 for ieprep-archive@odin.ietf.org; Wed, 8 Oct 2003 18:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NC5-0007on-Me for ieprep-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 18:54: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 SAA13714 for ; Wed, 8 Oct 2003 18:53:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NC2-0005Vy-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 18:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7NC2-0005Vv-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 18:54:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NBx-0007nN-Ao; Wed, 08 Oct 2003 18: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 1A7NBw-0007n8-6i for ieprep@optimus.ietf.org; Wed, 08 Oct 2003 18:54:00 -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 SAA13711 for ; Wed, 8 Oct 2003 18:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NBs-0005Vh-00 for ieprep@ietf.org; Wed, 08 Oct 2003 18:53:56 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1A7NBs-0005Vd-00 for ieprep@ietf.org; Wed, 08 Oct 2003 18:53:56 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98Mrl6U013396; Wed, 8 Oct 2003 18:53:47 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98Mrlii013395; Wed, 8 Oct 2003 18:53:47 -0400 (EDT) Date: Wed, 8 Oct 2003 18:53:47 -0400 (EDT) From: Scott Bradner Message-Id: <200310082253.h98Mrlii013395@newdev.harvard.edu> To: carlberg@g11.org.uk, ieprep@ietf.org, Janet.Gunn@DynCorp.com Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AB96@chntex04.is.dyncorp.com> 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: , > Substance > 1.2 third para > I have always understood that jitter was more important than delay for VoIP, > but you do not mention it. I'm not sure that jitter per se is a big issue - the distribution of delay is - most of the packets need to get to the other end within a reasonable limit - that can be because the basic delay is near the limit and there is no jitter or the basic latency is less and the jitter brings the delay to thye limit. Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Oct 8 19:27:23 2003 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 TAA14726 for ; Wed, 8 Oct 2003 19:27:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nhu-0000lf-QE for ieprep-archive@odin.ietf.org; Wed, 08 Oct 2003 19:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98NR22A002945 for ieprep-archive@odin.ietf.org; Wed, 8 Oct 2003 19:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nhu-0000lQ-Lp for ieprep-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 19:27:02 -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 TAA14721 for ; Wed, 8 Oct 2003 19:26:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Nhs-0005qO-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 19:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Nhs-0005qL-00 for ieprep-web-archive@ietf.org; Wed, 08 Oct 2003 19:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Nht-0000kf-3y; Wed, 08 Oct 2003 19:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7NhO-0000jj-Ml for ieprep@optimus.ietf.org; Wed, 08 Oct 2003 19:26: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 TAA14704 for ; Wed, 8 Oct 2003 19:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7NhN-0005pz-00 for ieprep@ietf.org; Wed, 08 Oct 2003 19:26:29 -0400 Received: from massive.its.bldrdoc.gov ([132.163.64.201]) by ietf-mx with esmtp (Exim 4.12) id 1A7NhM-0005pY-00 for ieprep@ietf.org; Wed, 08 Oct 2003 19:26:28 -0400 Received: from andydesktop (localhost.0.0.127.in-addr.arpa [127.0.0.1] (may be forged)) by massive.its.bldrdoc.gov (8.12.8p1/8.12.8) with ESMTP id h98NPhkE008115; Wed, 8 Oct 2003 17:25:44 -0600 (MDT) From: "Andrew Thiessen" To: "'Scott Bradner'" , , , Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Date: Wed, 8 Oct 2003 17:23:57 -0600 Message-ID: <009d01c38df3$3fbe20a0$2041a384@andydesktop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200310082253.h98Mrlii013395@newdev.harvard.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 Right... Jitter is important in that the size of the jitter buffer adds to the overall mouth-to-ear delay and that an accurate jitter buffer size selection is critical. If the jitter buffer size is smaller than the delay variation on the network, voice traffic will necessarily be dropped. If the jitter buffer is appropriately sized, the only impact jitter should have is the delay that the buffer adds. Whether or not a voice application can sustain a higher drop rate is fairly dependent on the codec that is used. For instance, a G-711 codec is more resilient to loss than a G-729 codec. The drop rate of a cloud has a direct impact on the quality of the voice traffic. For instance, we have lab tests that show with certain codecs that the estimated MOS score drops by 1 for every 5% increase in loss. Drop rates in elastic applications are typically more tolerant of drop due somewhat to the protocols that are used. For instance, TCP has a built in mechanism to retransmit lost packets, where UDP does not. Email and web browsing would therefore be much more resilient to loss in that a session with loss is easier to maintain with TCP than UDP. Would it take forever to get email and see a web page with high loss? Yes, but you would see it eventually. With VoIP, you may be able to maintain some type of conversation, but the quality could be so bad that there wouldn't be any point. Andy -----Original Message----- From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Scott Bradner Sent: Wednesday, October 08, 2003 3:54 PM To: carlberg@g11.org.uk; ieprep@ietf.org; Janet.Gunn@DynCorp.com Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt > Substance > 1.2 third para > I have always understood that jitter was more important than delay for VoIP, > but you do not mention it. I'm not sure that jitter per se is a big issue - the distribution of delay is - most of the packets need to get to the other end within a reasonable limit - that can be because the basic delay is near the limit and there is no jitter or the basic latency is less and the jitter brings the delay to thye limit. Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Oct 9 01:39:28 2003 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 BAA24567 for ; Thu, 9 Oct 2003 01:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7TVx-0000pv-HV for ieprep-archive@odin.ietf.org; Thu, 09 Oct 2003 01:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h995d5oQ003209 for ieprep-archive@odin.ietf.org; Thu, 9 Oct 2003 01:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7TVx-0000pg-Ci for ieprep-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 01:39: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 BAA24554 for ; Thu, 9 Oct 2003 01:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7TVu-0001gE-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 01:39:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7TVt-0001gB-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 01:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7TVt-0000oV-W6; Thu, 09 Oct 2003 01:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7TVR-0000o1-Af for ieprep@optimus.ietf.org; Thu, 09 Oct 2003 01:38: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 BAA24542 for ; Thu, 9 Oct 2003 01:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7TVO-0001fv-00 for ieprep@ietf.org; Thu, 09 Oct 2003 01:38:30 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1A7TVN-0001fZ-00 for ieprep@ietf.org; Thu, 09 Oct 2003 01:38:29 -0400 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h995aaxL024959 for ; Thu, 9 Oct 2003 01:38:00 -0400 Received: from KCCLUST05EVS1.ugd.att.com (135.38.164.87) by attrh3i.attrh.att.com (6.5.032) id 3F77069100290CC5; Thu, 9 Oct 2003 01:36:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] I-D ACTION:draft-ietf-ieprep-framework-06.txt Date: Thu, 9 Oct 2003 00:37:59 -0500 Message-ID: <71B1F34748CCC143B91430FCE861134F0203A148@KCCLUST05EVS1.ugd.att.com> Thread-Topic: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Thread-Index: AcON87P81PNpLYc8RQiPTzZjkxjWzgANBryw From: "Dvorak, Charles A (Chuck)" To: "Andrew Thiessen" , "Scott Bradner" , , , 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 Are you talking about random loss or bursty loss? (The former is a = curiosity but only the latter is realistic) -----Original Message----- From: Andrew Thiessen [mailto:andrew@its.bldrdoc.gov] Sent: Wednesday, October 08, 2003 7:24 PM To: 'Scott Bradner'; carlberg@g11.org.uk; ieprep@ietf.org; Janet.Gunn@DynCorp.com Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Right... Jitter is important in that the size of the jitter buffer adds to the overall mouth-to-ear delay and that an accurate jitter buffer size selection is critical. If the jitter buffer size is smaller than the delay variation on the network, voice traffic will necessarily be dropped. If the jitter buffer is appropriately sized, the only impact jitter should have is the delay that the buffer adds. Whether or not a voice application can sustain a higher drop rate is fairly dependent on the codec that is used. For instance, a G-711 codec is more resilient to loss than a G-729 codec. The drop rate of a cloud has a direct impact on the quality of the voice traffic. For instance, we have lab tests that show with certain codecs that the estimated MOS score drops by 1 for every 5% increase in loss. Drop rates in elastic applications are typically more tolerant of drop due somewhat to the protocols that are used. For instance, TCP has a built in mechanism to retransmit lost packets, where UDP does not. Email and web browsing would therefore be much more resilient to loss in that a session with loss is easier to maintain with TCP than UDP. Would it take forever to get email and see a web page with high loss? Yes, but you would see it eventually. With VoIP, you may be able to maintain some type of conversation, but the quality could be so bad that there wouldn't be any point. Andy _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Oct 9 09:15:30 2003 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 JAA18550 for ; Thu, 9 Oct 2003 09:15:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7adI-0002Y0-50 for ieprep-archive@odin.ietf.org; Thu, 09 Oct 2003 09:15:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99DF8Pa009786 for ieprep-archive@odin.ietf.org; Thu, 9 Oct 2003 09:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7adI-0002Xl-0O for ieprep-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 09:15:08 -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 JAA18537 for ; Thu, 9 Oct 2003 09:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7adG-00069D-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 09:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7adF-00069A-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 09:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7adB-0002Wz-2k; Thu, 09 Oct 2003 09:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7aci-0002WI-JM for ieprep@optimus.ietf.org; Thu, 09 Oct 2003 09:14: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 JAA18518 for ; Thu, 9 Oct 2003 09:14:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7acg-000693-00 for ieprep@ietf.org; Thu, 09 Oct 2003 09:14:30 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A7acg-00068z-00 for ieprep@ietf.org; Thu, 09 Oct 2003 09:14:30 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h99DESlN010000; Thu, 9 Oct 2003 15:14:29 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DVJ7W2; Thu, 9 Oct 2003 15:17:37 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Oct 2003 15:13:52 +0200 Message-ID: <8C1856C372A7574291A56C3B7000A7AEC5C6DE@eestqnt104> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Susana Sabater (ML/EEM)" To: "'Nguyen, An'" Cc: "'ieprep@ietf.org'" Subject: RE: [Ieprep] IP Transport of WPS traffic Date: Thu, 9 Oct 2003 15:14:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 An,=20 You are mentioning WPS, is this requirement formulated just for = networks operating in US? Cheers, /Susana -----Original Message----- From: Gunn, Janet [mailto:Janet.Gunn@DynCorp.com] Sent: mi=E9rcoles, 08 de octubre de 2003 21:17 To: 'Nguyen, An'; 'ieprep@ietf.org' Subject: RE: [Ieprep] IP Transport of WPS traffic An, Thanks for the fixed diagram. Are you considering the case of an IP backbone WITHIN a single WPS-Supporting Wireless Service Provider, or are you considering the = case of an IP based long distance provider connecting two distinct = WPS-Supporting Wireless Service Providers? Or both? Your "need" seems to address the second case, but I think the first case needs to be addressed too. Are you assuming that the IP network is a "private" IP network, or are = you assuming it to be the "Big I" Internet? There are similar needs for the "GETS to WPS" and "WPS to GETS" case, = if there is an IP network between the WPS-Supporting Wireless Service = Provider and the GETS-Supporting LEC or IXC. Since you are assuming no congestion in the IP part, the focus is on = getting the relevant ISUP parameters ((CPC parameter =3D HPC) for GETS, and = ((CPC parameter =3D HPC) PLUS (Precedence parameter Precedence Level =3D 0 = through 4, (based on calling party's Service User Priority), and MLPP Service = Domain =3D NCS Wireless Priority Service-1 through NCS Wireless Priority Service-5 (again based on calling party's Service User Priority))) from the originating WPS-Supporting Wireless Service Provider to the = terminating WPS-Supporting Wireless Service Provider. Thanks for bringing this up. Janet -----Original Message----- From: Nguyen, An [mailto:nguyena@ncs.gov] Sent: Wednesday, October 08, 2003 2:52 PM To: 'ieprep@ietf.org' Subject: [Ieprep] IP Transport of WPS traffic Sorry for the messed-up diagram in the previous email due to the = limited number of characters per line in the SMTP format! I am sending a = fixed-up one. An -----Original Message----- From: Nguyen, An [mailto:nguyena@ncs.gov] Sent: Wednesday, October 08, 2003 2:27 PM To: 'ieprep@ietf.org' Subject: [Ieprep] IP Transport of WPS traffic Hi all, I have the following issue I like to discuss with all of you. Wireless Priority Service currently allows authorized users to obtain = the next available radio resources (access and egress) on a priority basis. There are five levels defined by the FCC Regulation and Order as = follows: Level 1 - Executive Leadership and Policy Makers Level 2 - Disaster Response/Military Command and Control Level 3 - Public Health, Safety, and Law Enforcement Command Level 4 - Public Service/Utilities and Public Welfare Level 5 - Disaster Recovery WPS does not require any preemption feature. It will not disrupt any previously established calls and/or sessions. It allows WPS users wait = in the queue for radio access channels until the previous calls are = completed before they can make WPS calls . WPS is now available on one of the GSM-based networks. It is not yet available on any CDMA-based networks.=20 Below is scenario where IP networks are involved in the WPS calls. -------------- -------------- --------------- - - - - - - - - - - - -=20 - - - - - - - WPS ----------- IP ------------ WPS - - (GSM/ - - - - (GSM/ - - CDMA) - - - - CDMA) - = =20 - - - - - - -------------- -------------- --------------- Assumption: No congestion is in the IP backbone for now. Need: There is a need for WPS priority markers associated with WPS = calls originated in one wireless network to traverse IP networks and get = into another wireless network.=20 Requirement: It is required that IP network must have capability to = carry markers associated with WPS calls across its backbone network so that, = for the lack of better words, WPS can have end-to-end priority. Since the IEPREP WG is chartered to discuss requirements related to emergency preparedness, I would like to share this requirement with = the group.=20 Regards, An Nguyen _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Oct 9 10:03:27 2003 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 KAA20163 for ; Thu, 9 Oct 2003 10:03:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bNh-0004vz-6Q for ieprep-archive@odin.ietf.org; Thu, 09 Oct 2003 10:03:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99E35Kb018955 for ieprep-archive@odin.ietf.org; Thu, 9 Oct 2003 10:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bNg-0004vd-Ue for ieprep-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 10:03:04 -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 KAA20131 for ; Thu, 9 Oct 2003 10:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7bNe-0006eq-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 10:03:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7bNe-0006em-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 10:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bNc-0004u5-UK; Thu, 09 Oct 2003 10:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bMo-0004te-0d for ieprep@optimus.ietf.org; Thu, 09 Oct 2003 10:02: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 KAA20106 for ; Thu, 9 Oct 2003 10:02:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7bMl-0006eQ-00 for ieprep@ietf.org; Thu, 09 Oct 2003 10:02:07 -0400 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1A7bMl-0006e6-00 for ieprep@ietf.org; Thu, 09 Oct 2003 10:02:07 -0400 Received: (qmail 10659 invoked from network); 9 Oct 2003 14:01:35 -0000 Received: from pool-141-157-11-220.balt.east.verizon.net (HELO albers) (141.157.11.220) by uk.simply.net with SMTP; 9 Oct 2003 14:01:35 -0000 From: "Ken Carlberg" To: "'Gunn, Janet'" Cc: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Date: Thu, 9 Oct 2003 10:00:43 -0400 Message-ID: <004601c38e6d$bc1f8e70$7301a8c0@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AB96@chntex04.is.dyncorp.com> 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 > Substance > 1.2 third para > I have always understood that jitter was more important than delay for > VoIP, but you do not mention it. The section you refer to focuses on published material relating to VoIP, neither of which focuses on jitter. So its not so much a case of my choosing to not discuss jitter, but that those papers did not. If there is a paper with some stats that makes an argument for what you state above, please send it to me and I'll fold it in the section. In the meantime, I can add a comment later on in the diff-serv section that mentions the use of EF as a mechanism for addressing jitter. > 1.2 fourth para > This is stated as the opposite of what I have always understood. I have > always seen it that VoIP applications can tolerate a higher drop rate, and > even a moderate delay, as long as jitter is very small. Conversely > elastic > applications such as email and web browsing can tolerate high jitter and > delay, but need a low drop rate (because in email and web browsing the > dropped packets need to be retransmitted, but in VoIP, if they are dropped > you forget about them). Even a drop rate of "5%" is considered a very > high drop rate in a (data) world where the starting point for drop rates > is 10 to the minus 6. Again, if there is a paper/publication that you can cite, that would be very helpful. Many times there are caveats to each position taken. The use of FEC, transcoding (see the NRL work that Ran mentioned awhile back), interleaving (purposely placing packets out of order), etc., can improve the perceived quality of a VoIP flow. The lack of additional mechanisms or functions in those citations is probably an obvious thing that I should state in that section. As for elastic applications, there are two things to focus on: congestion collapse and buffer overflow. I've seen stats of TCP flows operating (barely) at sustained loss rates of ~40%. Buffer overflow is application specific and can cause connections to break at even modest levels of loss (ie, before congestion collapse). But to be fair, if I can't find suitable published stats, I will alter/remove the 4'th paragraph. > 4.4 > first para > > The statement that "the user authenticates himself... using a PIN" is true > for GETS but not for WPS, nor for line authentication, nor for other > related > programs, and therefore not for "PSTN" in general. If you said "the user > authenticates himself as usual to the network" it would be a valid > statement. Ok, I'll remove the word "PIN". > Editorial > > Section 1 > First para > " Best effort ...infers..." should be "Best effort ... implies ..." > ("infers" = "deduces") ok > Third para > Do you mean "stub domain" or "single domain"? The statement would seem to > also apply to a single domain "bridging" scenario. I meant stub domains. I'm not exactly sure what you mean by a 'single domain "bridging" scenario'. What is being bridged? > 1.2 > first para > It would be clearer if you said "... though not necessarily Voice over IP > which is not IP telephony" , instead of just "... though not necessarily > Voice over IP I'll clarify the sentence > Section 3 > Last line > Should be "violate", not "violet". Ok > Section 4.1.5 > MEGACO (RFC 3015) has been "obsoleted" by Gateway Control Protocol Version > 1 > (RFC 3525) The statement that priority 0 is the lowest and priority 15 is > the highest is in 3525 but not in 3015. ok > 4.4 last para > says "IEPS" rather than "ETS". Is this intentional? I'll switch it to ETS > 4.5 last para > "meetings" should be "meeting" ok > Section 5, text after figure 1 > Do you mean "Grade of Service" (= blocking probability based on Erlang's > formulae) or "Quality of Service" (= jitter, delay, drop rate)? Should be QoS -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Oct 9 10:29:29 2003 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 KAA22519 for ; Thu, 9 Oct 2003 10:29: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 1A7bmr-0006ss-Se for ieprep-archive@odin.ietf.org; Thu, 09 Oct 2003 10:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99ET5ab026448 for ieprep-archive@odin.ietf.org; Thu, 9 Oct 2003 10:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bmr-0006sO-L6 for ieprep-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 10:29: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 KAA22511 for ; Thu, 9 Oct 2003 10:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7bmp-00072N-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 10:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7bmo-00072J-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 10:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bmn-0006qg-3X; Thu, 09 Oct 2003 10:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7blv-0006kx-Fc for ieprep@optimus.ietf.org; Thu, 09 Oct 2003 10:28: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 KAA22476 for ; Thu, 9 Oct 2003 10:27:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7blt-000719-00 for ieprep@ietf.org; Thu, 09 Oct 2003 10:28:05 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1A7bls-000710-00 for ieprep@ietf.org; Thu, 09 Oct 2003 10:28:04 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h99ERu6U021480; Thu, 9 Oct 2003 10:27:56 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h99ERus3021479; Thu, 9 Oct 2003 10:27:56 -0400 (EDT) Date: Thu, 9 Oct 2003 10:27:56 -0400 (EDT) From: Scott Bradner Message-Id: <200310091427.h99ERus3021479@newdev.harvard.edu> To: carlberg@g11.org.uk, ieprep@ietf.org, Janet.Gunn@DynCorp.com, sob@harvard.edu Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AB9E@chntex04.is.dyncorp.com> 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: , > So what > you really want to say is that, say, "95% of the packets must have a delay > of less than 300 milliseconds", recognizing that 5% of the packets may get > dropped if the buffer mechanism at the receiver imposes a consistent 300 > millisecond delay. that is just the right idea Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Oct 9 10:50:52 2003 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 KAA20165 for ; Thu, 9 Oct 2003 10:03:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bNh-0004w8-8E for ieprep-archive@odin.ietf.org; Thu, 09 Oct 2003 10:03:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99E35hB018966 for ieprep-archive@odin.ietf.org; Thu, 9 Oct 2003 10:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bNh-0004vi-31 for ieprep-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 10:03: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 KAA20132 for ; Thu, 9 Oct 2003 10:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7bNe-0006et-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 10:03:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7bNe-0006en-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 10:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bNd-0004uD-8b; Thu, 09 Oct 2003 10:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bN9-0004to-Do for ieprep@optimus.ietf.org; Thu, 09 Oct 2003 10:02:31 -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 KAA20120 for ; Thu, 9 Oct 2003 10:02:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7bN7-0006ei-00 for ieprep@ietf.org; Thu, 09 Oct 2003 10:02:29 -0400 Received: from sonnet1.is.dyncorp.com ([131.131.11.68]) by ietf-mx with esmtp (Exim 4.12) id 1A7bN6-0006ef-00 for ieprep@ietf.org; Thu, 09 Oct 2003 10:02:28 -0400 Received: from chntex04.is.dyncorp.com (chntex04.is.dyncorp.com [131.131.133.214]) by sonnet1.is.dyncorp.com (8.12.8/8.12.8) with ESMTP id h99E2bTO005035; Thu, 9 Oct 2003 10:02:37 -0400 (EDT) Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Oct 2003 10:00:28 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AB9E@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Scott Bradner'" , carlberg@g11.org.uk, ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Date: Thu, 9 Oct 2003 10:00:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , To clarify what I mean. If you have a long, but consistent delay (say of the order of .5 seconds (500 milliseconds) in an intercontinental satellite call) it is very irritating from a conversation point of view- figuring out when it is "your turn to talk", and avoiding talking over each other. But the speech quality is perfectly intelligible. But if you have a highly variable delay, ranging from, say, 100 milliseconds to 500 milliseconds, with an average delay of 300 milliseconds, you have a high probability of "gaps" in the middle of words, even if there is no packet loss. You can, of course, buffer all the packets to the equivalent of 500 milliseconds delay, in which case the speech is intelligible, but then you gain no advantage from the fact that the average delay is 300 milliseconds instead of 500 milliseconds. You could thus say that what is important is the "maximum delay" (rather than the combination of "average delay" and "jitter"). But in the real world, there is no such thing as an upper bound on delay (except as it is enforced by dropping "late" packets), but there is a distribution. So what you really want to say is that, say, "95% of the packets must have a delay of less than 300 milliseconds", recognizing that 5% of the packets may get dropped if the buffer mechanism at the receiver imposes a consistent 300 millisecond delay. This is what I mean by "jitter is important". I would be equally satisfied by saying "distribution of delay" is important, But neither "average delay" nor "maximum delay", by themselves, are sufficient criteria. -----Original Message----- From: Scott Bradner [mailto:sob@harvard.edu] Sent: Wednesday, October 08, 2003 6:54 PM To: carlberg@g11.org.uk; ieprep@ietf.org; Gunn, Janet Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt > Substance > 1.2 third para > I have always understood that jitter was more important than delay for VoIP, > but you do not mention it. I'm not sure that jitter per se is a big issue - the distribution of delay is - most of the packets need to get to the other end within a reasonable limit - that can be because the basic delay is near the limit and there is no jitter or the basic latency is less and the jitter brings the delay to thye limit. Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Oct 9 11:15:52 2003 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 KAA22521 for ; Thu, 9 Oct 2003 10:29: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 1A7bmr-0006st-Sw for ieprep-archive@odin.ietf.org; Thu, 09 Oct 2003 10:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99ET52P026446 for ieprep-archive@odin.ietf.org; Thu, 9 Oct 2003 10:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bmr-0006sP-Mp for ieprep-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 10:29: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 KAA22512 for ; Thu, 9 Oct 2003 10:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7bmp-00072Q-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 10:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7bmo-00072K-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 10:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bmn-0006qu-Jo; Thu, 09 Oct 2003 10:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7bmg-0006qC-EN for ieprep@optimus.ietf.org; Thu, 09 Oct 2003 10:28:54 -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 KAA22502 for ; Thu, 9 Oct 2003 10:28:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7bme-000729-00 for ieprep@ietf.org; Thu, 09 Oct 2003 10:28:52 -0400 Received: from sonnet1.is.dyncorp.com ([131.131.11.68]) by ietf-mx with esmtp (Exim 4.12) id 1A7bmd-000726-00 for ieprep@ietf.org; Thu, 09 Oct 2003 10:28:51 -0400 Received: from chntex04.is.dyncorp.com (chntex04.is.dyncorp.com [131.131.133.214]) by sonnet1.is.dyncorp.com (8.12.8/8.12.8) with ESMTP id h99ET1TO030656; Thu, 9 Oct 2003 10:29:01 -0400 (EDT) Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Oct 2003 10:26:53 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AB9F@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Andrew Thiessen'" , "'Scott Bradner'" , carlberg@g11.org.uk, ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Date: Thu, 9 Oct 2003 10:26:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Drop rates. It all depends on where you are looking. I agree that from an end-user or end-application perspective, you can say that VoIP needs a lower drop rate than say email or web access (using TCP). The dropped VoIP packets are gone forever, but the dropped TCP packets will be retransmitted, and will get there "eventually". But from a network congestion perspective, the "ranking" is reversed. The dropped VoIP packets are gone and do not contribute to additional congestion. The retransmitted TCP packets add to the traffic volume, and make the congestion worse. From a simplified perspective, you could say that a 5% drop rate for TCP packets results is at least (because you have to "compound" that 5% on each retransmission) 5% additional TCP traffic offered to the network. Not something that is desirable in an already congested network. I think my concerns can be addressed by minor rewording, or a parenthetical comment. Janet -----Original Message----- From: Andrew Thiessen [mailto:andrew@its.bldrdoc.gov] Sent: Wednesday, October 08, 2003 7:24 PM To: 'Scott Bradner'; carlberg@g11.org.uk; ieprep@ietf.org; Gunn, Janet Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Right... Jitter is important in that the size of the jitter buffer adds to the overall mouth-to-ear delay and that an accurate jitter buffer size selection is critical. If the jitter buffer size is smaller than the delay variation on the network, voice traffic will necessarily be dropped. If the jitter buffer is appropriately sized, the only impact jitter should have is the delay that the buffer adds. Whether or not a voice application can sustain a higher drop rate is fairly dependent on the codec that is used. For instance, a G-711 codec is more resilient to loss than a G-729 codec. The drop rate of a cloud has a direct impact on the quality of the voice traffic. For instance, we have lab tests that show with certain codecs that the estimated MOS score drops by 1 for every 5% increase in loss. Drop rates in elastic applications are typically more tolerant of drop due somewhat to the protocols that are used. For instance, TCP has a built in mechanism to retransmit lost packets, where UDP does not. Email and web browsing would therefore be much more resilient to loss in that a session with loss is easier to maintain with TCP than UDP. Would it take forever to get email and see a web page with high loss? Yes, but you would see it eventually. With VoIP, you may be able to maintain some type of conversation, but the quality could be so bad that there wouldn't be any point. Andy -----Original Message----- From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Scott Bradner Sent: Wednesday, October 08, 2003 3:54 PM To: carlberg@g11.org.uk; ieprep@ietf.org; Janet.Gunn@DynCorp.com Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt > Substance > 1.2 third para > I have always understood that jitter was more important than delay for VoIP, > but you do not mention it. I'm not sure that jitter per se is a big issue - the distribution of delay is - most of the packets need to get to the other end within a reasonable limit - that can be because the basic delay is near the limit and there is no jitter or the basic latency is less and the jitter brings the delay to thye limit. Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Oct 9 12:02:03 2003 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 MAA25725 for ; Thu, 9 Oct 2003 12:02:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dES-0004Iz-Bl for ieprep-archive@odin.ietf.org; Thu, 09 Oct 2003 12:01:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99G1eBQ016543 for ieprep-archive@odin.ietf.org; Thu, 9 Oct 2003 12:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dES-0004Ik-6g for ieprep-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 12:01:40 -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 MAA25677 for ; Thu, 9 Oct 2003 12:01:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7dEQ-0000Hp-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 12:01:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7dEQ-0000Hm-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 12:01:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dDy-00046x-Cm; Thu, 09 Oct 2003 12:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dDZ-0003wn-PR for ieprep@optimus.ietf.org; Thu, 09 Oct 2003 12:00:47 -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 MAA25636 for ; Thu, 9 Oct 2003 12:00:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7dDY-0000H3-00 for ieprep@ietf.org; Thu, 09 Oct 2003 12:00:44 -0400 Received: from sonnet1.is.dyncorp.com ([131.131.11.68]) by ietf-mx with esmtp (Exim 4.12) id 1A7dDX-0000H0-00 for ieprep@ietf.org; Thu, 09 Oct 2003 12:00:43 -0400 Received: from chntex04.is.dyncorp.com (chntex04.is.dyncorp.com [131.131.133.214]) by sonnet1.is.dyncorp.com (8.12.8/8.12.8) with ESMTP id h99G0sTO003017; Thu, 9 Oct 2003 12:00:54 -0400 (EDT) Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Oct 2003 11:58:46 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915ABA1@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Ken Carlberg'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt Date: Thu, 9 Oct 2003 11:58:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , "Bridging" as in James's topology paper. Where the "call" originates and terminates in the CSN, but passes through a single IP domain in between. SO not a "stub" because it is neither source nor destination. But possessing the other "single domain" characteristics. -----Original Message----- From: Ken Carlberg [mailto:carlberg@g11.org.uk] > 4.4 > Third para > Do you mean "stub domain" or "single domain"? The statement would seem to > also apply to a single domain "bridging" scenario. I meant stub domains. I'm not exactly sure what you mean by a 'single domain "bridging" scenario'. What is being bridged? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Oct 9 14:34:29 2003 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 OAA02859 for ; Thu, 9 Oct 2003 14:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fbx-0006eq-VC for ieprep-archive@odin.ietf.org; Thu, 09 Oct 2003 14:34:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99IY5iH025588 for ieprep-archive@odin.ietf.org; Thu, 9 Oct 2003 14:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fbx-0006ed-QC for ieprep-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 14:34: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 OAA02847 for ; Thu, 9 Oct 2003 14:33:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7fbv-0002Sz-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 14:34:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7fbu-0002Sv-00 for ieprep-web-archive@ietf.org; Thu, 09 Oct 2003 14:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fbt-0006dt-R3; Thu, 09 Oct 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7fbW-0006dE-CS for ieprep@optimus.ietf.org; Thu, 09 Oct 2003 14:33:39 -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 OAA02832 for ; Thu, 9 Oct 2003 14:33:29 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7fbT-0002SZ-00 for ieprep@ietf.org; Thu, 09 Oct 2003 14:33:35 -0400 Received: from imo-r05.mx.aol.com ([152.163.225.101]) by ietf-mx with esmtp (Exim 4.12) id 1A7fbT-0002Rz-00 for ieprep@ietf.org; Thu, 09 Oct 2003 14:33:35 -0400 Received: from Mpierce1@aol.com by imo-r05.mx.aol.com (mail_out_v36_r1.1.) id 5.112.29956451 (17377); Thu, 9 Oct 2003 14:29:37 -0400 (EDT) Message-ID: <112.29956451.2cb70311@aol.com> Date: Thu, 9 Oct 2003 14:29:37 EDT Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt To: sob@harvard.edu, carlberg@g11.org.uk, ieprep@ietf.org, Janet.Gunn@DynCorp.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_112.29956451.2cb70311_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_112.29956451.2cb70311_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/8/2003 6:54:38 PM Eastern Standard Time, sob@harvard.edu writes: > I'm not sure that jitter per se is a big issue - the distribution of > delay is - most of the packets need to get to the other end within > a reasonable limit - that can be because the basic delay is near the > limit and there is no jitter or the basic latency is less and the jitter > brings the delay to thye limit. > Problem seems partly to be "What is your definition of jitter?" I believe jitter is the same as "the distribution of delay". In any case, "jitter" (or packet delay variation, as I'd rather call it, as ITU-T SG13 does) is an important issue. Delay is an important isses. Packet loss is an important issue. It's kind of hard to say that one is "more important" than the other. Mike --part1_112.29956451.2cb70311_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 10/8/2= 003 6:54:38 PM Eastern Standard Time, sob@harvard.edu writes:


I'm not sure that jitter pe= r se is a big issue - the distribution of=20
delay is - most of the packets need to get to the other end within=20
a reasonable limit - that can be because the basic delay is near the
limit and there is no jitter or the basic latency is less and the jitter
brings the delay to thye limit.


Problem seems partly to be "What is your definition of jitter?" I believ= e jitter is the same as "the distribution of delay".

In any case, "jitter" (or packet delay variation, as I'd rather call it,= as ITU-T SG13 does) is an important issue. Delay is an important isses. Pac= ket loss is an important issue. It's kind of hard to say that one is "more i= mportant" than the other.

Mike
--part1_112.29956451.2cb70311_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Oct 10 14:53:36 2003 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 OAA12357 for ; Fri, 10 Oct 2003 14:53:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82O2-0002EK-0K for ieprep-archive@odin.ietf.org; Fri, 10 Oct 2003 14:53:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIrDtU008566 for ieprep-archive@odin.ietf.org; Fri, 10 Oct 2003 14:53:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82O1-0002E5-Re for ieprep-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:53:13 -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 OAA12312 for ; Fri, 10 Oct 2003 14:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82Ny-0007h8-00 for ieprep-web-archive@ietf.org; Fri, 10 Oct 2003 14:53:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A82Ny-0007h4-00 for ieprep-web-archive@ietf.org; Fri, 10 Oct 2003 14:53:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Nn-0002BP-UK; Fri, 10 Oct 2003 14:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Mq-00022j-Je for ieprep@optimus.ietf.org; Fri, 10 Oct 2003 14:52:00 -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 OAA12140 for ; Fri, 10 Oct 2003 14:51:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82Mn-0007d4-00 for ieprep@ietf.org; Fri, 10 Oct 2003 14:51:57 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx with esmtp (Exim 4.12) id 1A82Mm-0007d1-00 for ieprep@ietf.org; Fri, 10 Oct 2003 14:51:56 -0400 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Fri, 10 Oct 2003 14:51:49 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003101014514828289 for ; Fri, 10 Oct 2003 14:51:48 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2655.55) id <4MGAQ2CZ>; Fri, 10 Oct 2003 14:51:48 -0400 Message-Id: From: "King, Kimberly S." To: "'ieprep@ietf.org'" Date: Fri, 10 Oct 2003 14:51:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Subject: [Ieprep] No IEPREP meeting in Minneapolis 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: , There has been insufficient progress on chartered topics since the last IEPREP meeting to justify one in Minneapolis. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Oct 13 12:46:31 2003 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 MAA14894 for ; Mon, 13 Oct 2003 12:46: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 1A95pi-0003r2-Tu for ieprep-archive@odin.ietf.org; Mon, 13 Oct 2003 12:46:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DGkA5A014812 for ieprep-archive@odin.ietf.org; Mon, 13 Oct 2003 12:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95pi-0003qp-OS for ieprep-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 12:46: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 MAA14882 for ; Mon, 13 Oct 2003 12:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95pg-0005LM-00 for ieprep-web-archive@ietf.org; Mon, 13 Oct 2003 12:46:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A95pg-0005LJ-00 for ieprep-web-archive@ietf.org; Mon, 13 Oct 2003 12:46:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95pZ-0003oC-Hk; Mon, 13 Oct 2003 12:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95pM-0003nV-TP for ieprep@optimus.ietf.org; Mon, 13 Oct 2003 12:45:48 -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 MAA14868 for ; Mon, 13 Oct 2003 12:45:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95pL-0005Kw-00 for ieprep@ietf.org; Mon, 13 Oct 2003 12:45:47 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx with esmtp (Exim 4.12) id 1A95pK-0005Kt-00 for ieprep@ietf.org; Mon, 13 Oct 2003 12:45:46 -0400 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Mon, 13 Oct 2003 12:45:24 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003101312452306594 for ; Mon, 13 Oct 2003 12:45:23 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2655.55) id ; Mon, 13 Oct 2003 12:44:03 -0400 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Date: Mon, 13 Oct 2003 12:45:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] new tools for congestion? 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: , At least one ISP is talking about continuous service to "route around congestion, failures and scheduled maintenance using real- time traffic data instead of estimations that often proved inaccurate" http://www.nwfusion.com/news/2003/1013att.html?net _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Oct 13 21:52:29 2003 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 VAA09190 for ; Mon, 13 Oct 2003 21:52: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 1A9EM5-0004mg-8h for ieprep-archive@odin.ietf.org; Mon, 13 Oct 2003 21:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E1q9VA018386 for ieprep-archive@odin.ietf.org; Mon, 13 Oct 2003 21:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9EM4-0004mS-Vw for ieprep-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 21:52: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 VAA09181 for ; Mon, 13 Oct 2003 21:51:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9EM1-0004PB-00 for ieprep-web-archive@ietf.org; Mon, 13 Oct 2003 21:52:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9EM1-0004P8-00 for ieprep-web-archive@ietf.org; Mon, 13 Oct 2003 21:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ELw-0004k0-Vl; Mon, 13 Oct 2003 21:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ELa-0004hq-KD for ieprep@optimus.ietf.org; Mon, 13 Oct 2003 21:51:38 -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 VAA09145 for ; Mon, 13 Oct 2003 21:51:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ELX-0004OJ-00 for ieprep@ietf.org; Mon, 13 Oct 2003 21:51:35 -0400 Received: from clifden.donelan.com ([199.34.53.180]) by ietf-mx with esmtp (Exim 4.12) id 1A9ELX-0004OG-00 for ieprep@ietf.org; Mon, 13 Oct 2003 21:51:35 -0400 Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.36 #1) id 1A9ELV-00013X-00; Mon, 13 Oct 2003 21:51:33 -0400 Date: Mon, 13 Oct 2003 21:51:33 -0400 (EDT) From: Sean Donelan To: "King, Kimberly S." cc: "Ieprep (E-mail)" Subject: Re: [Ieprep] new tools for congestion? In-Reply-To: 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, 13 Oct 2003, King, Kimberly S. wrote: > At least one ISP is talking about continuous service to > "route around congestion, failures and scheduled maintenance using real- > time traffic data instead of estimations that often proved inaccurate" > http://www.nwfusion.com/news/2003/1013att.html?net Actually this isn't done in real-time. AT&T is using it as a traffic forcasting model. It collects the data once a day, and used for various modeling simulations. For example, verifying they still have redundancy on certain links or enough capacity in case something fails. AT&T has done some nice work, but it is evolutionary not revolutionary. Other providers have their own homegrown systems or use something like WANDL. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Oct 14 00:03:27 2003 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 AAA12330 for ; Tue, 14 Oct 2003 00:03:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9GOo-0001zu-TH for ieprep-archive@odin.ietf.org; Tue, 14 Oct 2003 00:03:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E436XX007672 for ieprep-archive@odin.ietf.org; Tue, 14 Oct 2003 00:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9GOo-0001zf-PL for ieprep-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 00:03:06 -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 AAA12325 for ; Tue, 14 Oct 2003 00:02:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9GOm-0005Ub-00 for ieprep-web-archive@ietf.org; Tue, 14 Oct 2003 00:03:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9GOl-0005UY-00 for ieprep-web-archive@ietf.org; Tue, 14 Oct 2003 00:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9GOi-0001yo-TS; Tue, 14 Oct 2003 00:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9GOd-0001yT-LO for ieprep@optimus.ietf.org; Tue, 14 Oct 2003 00:02:55 -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 AAA12322 for ; Tue, 14 Oct 2003 00:02:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9GOb-0005UV-00 for ieprep@ietf.org; Tue, 14 Oct 2003 00:02:53 -0400 Received: from kc-msxproto3.kc.umkc.edu ([134.193.143.160]) by ietf-mx with esmtp (Exim 4.12) id 1A9GOa-0005US-00 for ieprep@ietf.org; Tue, 14 Oct 2003 00:02:52 -0400 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Oct 2003 23:02:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] new tools for congestion? Date: Mon, 13 Oct 2003 23:02:50 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011080E8@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] new tools for congestion? Thread-Index: AcOR9caxHhcTom6MQUWwGS79Hh0VigACux0i From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Sean Donelan" , "King, Kimberly S." Cc: "Ieprep \(E-mail\)" X-OriginalArrivalTime: 14 Oct 2003 04:02:51.0195 (UTC) FILETIME=[096BA8B0:01C39208] 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 > Actually this isn't done in real-time. AT&T is using it as a traffic > forcasting model. It collects the data once a day, and used for > various modeling simulations. For example, verifying they still have > redundancy on certain links or enough capacity in case something = fails. =20 The cited nwfusion article talks about applying *tomography* for traffic matrix estimation (sprint labs has similar work, but using choice = models.) While it is not real-time, it is not just used for dimensioning purpose; = but also load balancing, fail-over(but at a larger time scale) and even=20 automated routing protocol configuration. =20 btw, AT&T and sprintlabs TM estimation techniques are published in=20 SIGCOMM 03 and SIGCOMM 02 respectively. I don't know how much it is used in practice. > AT&T has done some nice work, but it is evolutionary not = revolutionary. > Other providers have their own homegrown systems or use something like > WANDL. =20 I may be wrong. But, products like WANDL and Netdoctor support automated = configuration (to avoide manual errors) and serve as visualization tool (but, it is a generic tool.) For example, given a set of OSPF weights +=20 traffic demands, it can visualize the network in a graph form. In = certain=20 cases, it helps run a simulation to aid in the capacity forcasting = process.=20 So, it replaces some manual work. But, AT&T/sprintlabs work is to apply=20 heuristics to provide a solution for a specific task( TE estimation, = weight=20 optimization etc.) So, their is a difference between = "helping-to-understand- the-problem" and "solving-the-problem." =20 =20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Fri Oct 24 15:52:29 2003 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 PAA26563 for ; Fri, 24 Oct 2003 15:52: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 1AD7yj-0002i0-LF for ieprep-archive@odin.ietf.org; Fri, 24 Oct 2003 15:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OJq9TX010404 for ieprep-archive@odin.ietf.org; Fri, 24 Oct 2003 15:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7yj-0002hh-Cm for ieprep-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 15:52: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 PAA26495 for ; Fri, 24 Oct 2003 15:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7yg-0003LP-00 for ieprep-web-archive@ietf.org; Fri, 24 Oct 2003 15:52:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD7yg-0003LL-00 for ieprep-web-archive@ietf.org; Fri, 24 Oct 2003 15:52:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7yb-0002eo-Ny; Fri, 24 Oct 2003 15:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7ya-0002eZ-Ra for ieprep@optimus.ietf.org; Fri, 24 Oct 2003 15:52:00 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26479 for ; Fri, 24 Oct 2003 15:51:50 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AD7si-0001TP-Iv; Fri, 24 Oct 2003 15:45:56 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Fri, 24 Oct 2003 15:45:56 -0400 Subject: [Ieprep] Document Action: 'General Requirements for Emergency Telecommunication Service' to Informational RFC 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: , The IESG has approved following document: - 'General Requirements for Emergency Telecommunication Service ' as an Informational RFC This document is the product of the Internet Emergency Preparedness Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep