From architecture-discuss-bounces@ietf.org Tue May 16 16:16:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5x0-0007b9-V1; Tue, 16 May 2006 16:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5x0-0007aT-45 for architecture-discuss@ietf.org; Tue, 16 May 2006 16:15:26 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg5wx-0004YF-PB for architecture-discuss@ietf.org; Tue, 16 May 2006 16:15:26 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA07724 for ; Tue, 16 May 2006 13:15:19 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4GKFKr22888 for ; Tue, 16 May 2006 13:15:20 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 13:15:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 May 2006 13:14:12 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108025848A8@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QoS Signaling Status and Support Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjA== From: "Fleischman, Eric" To: X-OriginalArrivalTime: 16 May 2006 20:15:15.0620 (UTC) FILETIME=[71C62640:01C67925] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [arch-d] QoS Signaling Status and Support X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I've been away from QoS for several years, but am currently trying to become current again. I am surprised to note that the Next Steps in Signaling (NSIS; see http://www.ietf.org/html.charters/nsis-charter.html) WG exists within the IETF. My surprise stems from my own perception that Int-Serv proved to be a very unsatisfactory experience for our IETF community. Certainly, as a user, I personally was very disappointed that nothing useful (that I am aware of) came from that approach, because, had it worked, then the path forward for voice-video-data convergence would have been clearer. A few years back I started a thread on the ietf mailing list asking about the current state of RSVP, and I received a lot of feedback from IETF participants about how valuable RSVP-TE was proving to be for MPLS. That told me that a certain percentage of our community was excited about RSVP signaling for MPLS, and apparently were experiencing success using it, even though we were achieving similar results at that time through different means.=20 Anyway, in my mind, I formed a view that RSVP when used for hard-states such as Int-Serv didn't scale and had some ugly overheads that "hardened the network's arteries" while when used with MPLS it had apparently experienced satisfactory results. Does this perception jive with your view? If it does, why do you all think that it is successful for MPLS but not for Int-Serv? What do you believe the key factors are that make MPLS more successful than Int-Serv? Anyway, when I read the NSIS material, I can't escape the feeling that these people have a telephony mentality. Thus, in my own mind, I put them into the "bucket" of trying to apply hard state into the Internet to achieve SS7-like results. Is this an accurate interpretation of their work and mind-set? If so, then why do they think that NSIS will have a different result than Int-Serv?=20 How well accepted is the NSIS work within the IETF? For example, I note that their RFCs that I have read were all experimental and that they point to other experimental work such as Seamoby. From this alone I surmise that it is not mainstream. Is this accurate? If so, then why is the IETF sponsoring their WG? Most importantly, how can their work fit into historic IP architectural models?=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue May 16 16:19:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg60p-0001yE-A7; Tue, 16 May 2006 16:19:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg60n-0001y9-S4 for architecture-discuss@ietf.org; Tue, 16 May 2006 16:19:21 -0400 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fg60j-0004dI-7J for architecture-discuss@ietf.org; Tue, 16 May 2006 16:19:21 -0400 Received: (qmail 13833 invoked from network); 16 May 2006 20:15:17 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 16 May 2006 20:15:14 -0000 Received: from LIPC ([192.168.1.118]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 13:19:48 -0700 From: "Tony Li" To: "'Fleischman, Eric'" , Subject: RE: [arch-d] QoS Signaling Status and Support Date: Tue, 16 May 2006 13:19:02 -0700 Message-ID: <010901c67925$f90d3120$9a01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <474EEBD229DF754FB83D256004D02108025848A8@XCH-NW-6V1.nw.nos.boeing.com> Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjAAAILhg X-OriginalArrivalTime: 16 May 2006 20:19:48.0150 (UTC) FILETIME=[1436ED60:01C67926] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Eric, RSVP worked for TE purposes soley because TE is intra-domain. It would not scale to the inter-domain. Tony > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com] > Sent: Tuesday, May 16, 2006 1:14 PM > To: architecture-discuss@ietf.org > Subject: [arch-d] QoS Signaling Status and Support > > I've been away from QoS for several years, but am currently trying to > become current again. I am surprised to note that the Next Steps in > Signaling (NSIS; see > http://www.ietf.org/html.charters/nsis-charter.html) WG exists within > the IETF. My surprise stems from my own perception that > Int-Serv proved > to be a very unsatisfactory experience for our IETF community. > Certainly, as a user, I personally was very disappointed that nothing > useful (that I am aware of) came from that approach, because, had it > worked, then the path forward for voice-video-data convergence would > have been clearer. > > A few years back I started a thread on the ietf mailing list asking > about the current state of RSVP, and I received a lot of feedback from > IETF participants about how valuable RSVP-TE was proving to > be for MPLS. > That told me that a certain percentage of our community was excited > about RSVP signaling for MPLS, and apparently were > experiencing success > using it, even though we were achieving similar results at that time > through different means. > > Anyway, in my mind, I formed a view that RSVP when used for > hard-states > such as Int-Serv didn't scale and had some ugly overheads > that "hardened > the network's arteries" while when used with MPLS it had apparently > experienced satisfactory results. Does this perception jive with your > view? If it does, why do you all think that it is successful for MPLS > but not for Int-Serv? What do you believe the key factors are > that make > MPLS more successful than Int-Serv? > > Anyway, when I read the NSIS material, I can't escape the feeling that > these people have a telephony mentality. Thus, in my own mind, I put > them into the "bucket" of trying to apply hard state into the Internet > to achieve SS7-like results. Is this an accurate > interpretation of their > work and mind-set? If so, then why do they think that NSIS will have a > different result than Int-Serv? > > How well accepted is the NSIS work within the IETF? For > example, I note > that their RFCs that I have read were all experimental and that they > point to other experimental work such as Seamoby. From this alone I > surmise that it is not mainstream. Is this accurate? If so, > then why is > the IETF sponsoring their WG? Most importantly, how can their work fit > into historic IP architectural models? > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue May 16 16:36:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6Gc-0007Yp-4W; Tue, 16 May 2006 16:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6Ga-0007Ya-Fh for architecture-discuss@ietf.org; Tue, 16 May 2006 16:35:40 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6Ga-0005EM-50 for architecture-discuss@ietf.org; Tue, 16 May 2006 16:35:40 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA01443; Tue, 16 May 2006 15:35:39 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4GKZdr04966; Tue, 16 May 2006 13:35:39 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 13:35:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Tue, 16 May 2006 13:35:15 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108025848A9@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <010901c67925$f90d3120$9a01a8c0@tropos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjAAAILhgAABwF4A= From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 16 May 2006 20:35:38.0112 (UTC) FILETIME=[4A6FA000:01C67928] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony, Thank you for your quick reply!=20 I'd like to get your viewpoint on the following related topic:=20 Background: my employer has successfully used MPLS for both intra-domain and inter-domain. The latter was due to close cooperation and coordination with our major ISP, SITA.=20 Question: Why does MPLS have success stories like this when Int-Serv didn't? Or does it? What do you think? --Eric -----Original Message----- From: Tony Li [mailto:tli@tropos.com]=20 Sent: Tuesday, May 16, 2006 1:19 PM To: Fleischman, Eric; architecture-discuss@ietf.org Subject: RE: [arch-d] QoS Signaling Status and Support Eric, RSVP worked for TE purposes soley because TE is intra-domain. It would not scale to the inter-domain. Tony =20 > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com] > Sent: Tuesday, May 16, 2006 1:14 PM > To: architecture-discuss@ietf.org > Subject: [arch-d] QoS Signaling Status and Support >=20 > I've been away from QoS for several years, but am currently trying to=20 > become current again. I am surprised to note that the Next Steps in=20 > Signaling (NSIS; see > http://www.ietf.org/html.charters/nsis-charter.html) WG exists within=20 > the IETF. My surprise stems from my own perception that Int-Serv=20 > proved to be a very unsatisfactory experience for our IETF community. > Certainly, as a user, I personally was very disappointed that nothing > useful (that I am aware of) came from that approach, because, had it > worked, then the path forward for voice-video-data convergence would > have been clearer. >=20 > A few years back I started a thread on the ietf mailing list asking=20 > about the current state of RSVP, and I received a lot of feedback from > IETF participants about how valuable RSVP-TE was proving to be for=20 > MPLS. That told me that a certain percentage of our community was=20 > excited about RSVP signaling for MPLS, and apparently were > experiencing success > using it, even though we were achieving similar results at that time > through different means.=20 >=20 > Anyway, in my mind, I formed a view that RSVP when used for > hard-states > such as Int-Serv didn't scale and had some ugly overheads=20 > that "hardened > the network's arteries" while when used with MPLS it had apparently > experienced satisfactory results. Does this perception jive with your > view? If it does, why do you all think that it is successful for MPLS > but not for Int-Serv? What do you believe the key factors are=20 > that make > MPLS more successful than Int-Serv? >=20 > Anyway, when I read the NSIS material, I can't escape the feeling that > these people have a telephony mentality. Thus, in my own mind, I put=20 > them into the "bucket" of trying to apply hard state into the Internet > to achieve SS7-like results. Is this an accurate interpretation of=20 > their work and mind-set? If so, then why do they think that NSIS will=20 > have a different result than Int-Serv? >=20 > How well accepted is the NSIS work within the IETF? For > example, I note > that their RFCs that I have read were all experimental and that they > point to other experimental work such as Seamoby. From this alone I > surmise that it is not mainstream. Is this accurate? If so,=20 > then why is > the IETF sponsoring their WG? Most importantly, how can their work fit > into historic IP architectural models?=20 >=20 > _______________________________________________ > Architecture-discuss mailing list Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue May 16 16:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6aV-0002Bc-Jf; Tue, 16 May 2006 16:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6aU-0002BX-MV for architecture-discuss@ietf.org; Tue, 16 May 2006 16:56:14 -0400 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fg6aT-0006nd-2y for architecture-discuss@ietf.org; Tue, 16 May 2006 16:56:14 -0400 Received: (qmail 16936 invoked from network); 16 May 2006 20:52:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 16 May 2006 20:52:21 -0000 Received: from LIPC ([192.168.1.118]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 13:56:55 -0700 From: "Tony Li" To: "'Fleischman, Eric'" , , Subject: RE: [arch-d] QoS Signaling Status and Support Date: Tue, 16 May 2006 13:56:05 -0700 Message-ID: <011301c6792b$263c04a0$9a01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <474EEBD229DF754FB83D256004D02108025848A9@XCH-NW-6V1.nw.nos.boeing.com> Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjAAAILhgAABwF4AAAFDu4A== X-OriginalArrivalTime: 16 May 2006 20:56:55.0429 (UTC) FILETIME=[43C6BB50:01C6792B] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > I'd like to get your viewpoint on the following related topic: > Background: my employer has successfully used MPLS for both > intra-domain > and inter-domain. The latter was due to close cooperation and > coordination with our major ISP, SITA. > Question: Why does MPLS have success stories like this when Int-Serv > didn't? Or does it? What do you think? Eric, Well, IMHO, IntServ existed soley for the purpose of killing off ATM. Not that that succeeded, mind you, it was POS that killed it and MPLS/TE that drove in the final nail. In any case, once it was dead, interest in Int-Serv waned and shifted (appropriately, IMHO) to DiffServ. For obvious reasons, DiffServ is far preferable from the network's point of view. Another reason for MPLS succeeding lies in the old saw: "he who pays the bills makes the rules". The corollary for networking is: "ISPs dictate router features". ISPs never seemed seriously interested in Int-Serv. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 17 02:27:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFTe-0006pK-Qf; Wed, 17 May 2006 02:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFTe-0006pF-0C for architecture-discuss@ietf.org; Wed, 17 May 2006 02:25:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgEdx-0000g4-Mg for architecture-discuss@ietf.org; Wed, 17 May 2006 01:32:22 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgESb-0008Jg-Vp for architecture-discuss@ietf.org; Wed, 17 May 2006 01:20:42 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4H5KXLX007327; Wed, 17 May 2006 08:20:33 +0300 Date: Wed, 17 May 2006 08:20:33 +0300 (EEST) From: Pekka Savola To: "Fleischman, Eric" Subject: Re: [arch-d] QoS Signaling Status and Support In-Reply-To: <474EEBD229DF754FB83D256004D02108025848A8@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: References: <474EEBD229DF754FB83D256004D02108025848A8@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1467/Wed May 17 00:21:47 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.3 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Tue, 16 May 2006, Fleischman, Eric wrote: > My surprise stems from my own perception that Int-Serv proved > to be a very unsatisfactory experience for our IETF community. You shouldn't be surprised -- the QoS community is in denial, and has been for a long time. The thinking seems to go like this: "IntServ using RSVP was not succesful.. so the fault must have been at RSVP. Let's design a better version of RSVP!" > A few years back I started a thread on the ietf mailing list asking > about the current state of RSVP, and I received a lot of feedback from > IETF participants about how valuable RSVP-TE was proving to be for MPLS. I remember that discussion because I remember criticizing path-coupled signalling approaches :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 17 07:15:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgJzM-0005Nb-Dp; Wed, 17 May 2006 07:14:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgJzL-0005NW-D5 for architecture-discuss@ietf.org; Wed, 17 May 2006 07:14:47 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgJzK-0001pz-Vc for architecture-discuss@ietf.org; Wed, 17 May 2006 07:14:47 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k4HBEhKa013056; Wed, 17 May 2006 13:14:43 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k4HBEhZ1018965; Wed, 17 May 2006 13:14:43 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 13:14:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [arch-d] QoS Signaling Status and Support Date: Wed, 17 May 2006 13:14:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ5ew9yjAOamDZdTKe0aN+KXzmCRgAIvWmA From: "Tschofenig, Hannes" To: "Pekka Savola" , "Fleischman, Eric" X-OriginalArrivalTime: 17 May 2006 11:14:42.0706 (UTC) FILETIME=[18A9F720:01C679A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Pekka,=20 > On Tue, 16 May 2006, Fleischman, Eric wrote: > > My surprise stems from my own perception that Int-Serv proved > > to be a very unsatisfactory experience for our IETF community. >=20 > You shouldn't be surprised -- the QoS community is in denial, and has=20 > been for a long time. I guess you can explain this in more detail. >=20 > The thinking seems to go like this: "IntServ using RSVP was not=20 > succesful.. so the fault must have been at RSVP. Let's design a=20 > better version of RSVP!" Well, it is not that easy. Here are some major problems: * The IETF wants to develop e2e solutions. Other organizations are already happy if they get something accomplished for the wireless link or for intra-domain environment only.=20 This has an impact on the solution.=20 I am not sure how large the interest in the inter-domain QoS approaches are. =20 * Many organizations that care really, really about QoS see it as their job to develop their own QoS solution. They don't want to look at the IETF. These organizations sometimes develop solutions where the end host is not involved or where the intelligence is in the network (combined with some other convenient assumptions).=20 * Business model for QoS is complicated. This is a long discussion and mostly outside the IETF. It is basically about "Do we need QoS at all or is the Internet already good enough without any QoS mechanisms." The answer will depend on the person you ask and on the application you are considering.=20 > > A few years back I started a thread on the ietf mailing list asking > > about the current state of RSVP, and I received a lot of=20 > feedback from > > IETF participants about how valuable RSVP-TE was proving to=20 > be for MPLS. >=20 > I remember that discussion because I remember criticizing=20 > path-coupled=20 > signalling approaches :-) Fyi, the NSIS working group has spent some time also thinking about path-decoupled approaches and there was a huge interest in this subject. A number of presentations were given about this subject at past IETF meetings (and not only in the NSIS WG; also at the DCPEL "mini-BoF").=20 I remember your mailing list discussion thread and we took your comments serious; and not only your comments. Finally, I have to state that many of the path-coupled vs. path-decoupled signaling arguments differ only in a small detail if the scope of the work is QoS signaling in the access network.=20 =20 Ciao Hannes _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 17 07:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgJzT-0005Pp-Jk; Wed, 17 May 2006 07:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgJzS-0005Od-90 for architecture-discuss@ietf.org; Wed, 17 May 2006 07:14:54 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgJzR-0001q6-KZ for architecture-discuss@ietf.org; Wed, 17 May 2006 07:14:54 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k4HBEgS0002573; Wed, 17 May 2006 13:14:43 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k4HBEgcU007651; Wed, 17 May 2006 13:14:42 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 13:14:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [arch-d] QoS Signaling Status and Support Date: Wed, 17 May 2006 13:14:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjAAeqS+g From: "Tschofenig, Hannes" To: "Fleischman, Eric" , X-OriginalArrivalTime: 17 May 2006 11:14:42.0347 (UTC) FILETIME=[18732FB0:01C679A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Eric,=20 you raise an interesting topic. Please find my response below:=20 > -----Urspr=FCngliche Nachricht----- > Von: Fleischman, Eric [mailto:eric.fleischman@boeing.com]=20 > Gesendet: Dienstag, 16. Mai 2006 22:14 > An: architecture-discuss@ietf.org > Betreff: [arch-d] QoS Signaling Status and Support >=20 > I've been away from QoS for several years, but am currently trying to > become current again. I am surprised to note that the Next Steps in > Signaling (NSIS; see > http://www.ietf.org/html.charters/nsis-charter.html) WG exists within > the IETF. My surprise stems from my own perception that=20 > Int-Serv proved > to be a very unsatisfactory experience for our IETF community. > Certainly, as a user, I personally was very disappointed that nothing > useful (that I am aware of) came from that approach, because, had it > worked, then the path forward for voice-video-data convergence would > have been clearer. >=20 > A few years back I started a thread on the ietf mailing list asking > about the current state of RSVP, and I received a lot of feedback from > IETF participants about how valuable RSVP-TE was proving to=20 > be for MPLS. > That told me that a certain percentage of our community was excited > about RSVP signaling for MPLS, and apparently were=20 > experiencing success > using it, even though we were achieving similar results at that time > through different means.=20 >=20 > Anyway, in my mind, I formed a view that RSVP when used for=20 > hard-states > such as Int-Serv didn't scale and had some ugly overheads=20 > that "hardened > the network's arteries" while when used with MPLS it had apparently > experienced satisfactory results. Does this perception jive with your > view? If it does, why do you all think that it is successful for MPLS > but not for Int-Serv? What do you believe the key factors are=20 > that make > MPLS more successful than Int-Serv? >=20 > Anyway, when I read the NSIS material, I can't escape the feeling that > these people have a telephony mentality. What do you consider "telephony mentality" when you read about the NSIS = work?=20 > Thus, in my own mind, I put > them into the "bucket" of trying to apply hard state into the Internet > to achieve SS7-like results. Is this an accurate=20 > interpretation of their > work and mind-set? No, it is not.=20 I would rather argue that this is the case for RSVP-TE.=20 =20 > If so, then why do they think that NSIS will have a > different result than Int-Serv?=20 NSIS is a protocol suite where as IntServ (CL/GS) is a Quality of = Service model.=20 There are different QoS models being developed at the NSIS working = group.=20 =20 >=20 > How well accepted is the NSIS work within the IETF? For=20 > example, I note > that their RFCs that I have read were all experimental and that they > point to other experimental work such as Seamoby. Which documents do you mean?=20 The NSIS WG has a number of major documents in WGLC and GIST in 'AD = Evaluation' state.=20 > From this alone I > surmise that it is not mainstream. Is this accurate? If so,=20 > then why is > the IETF sponsoring their WG? Most importantly, how can their work fit > into historic IP architectural models? You are touching an entirely separate topic with these questions, namely "Should the IETF work on topics where deployment is not already happing = (or imminent)?" The IETF takes quite long to finish their work on almost any topic = (because of many reasons; yet another discussion thread necessary). So, = if you start your work in the IETF if a customer is knocking on the door = then it will not be ready in time. There are other working groups that = just rubber-stamp the work done outside the IETF.=20 I have raised this question in past plenaries but I received only = unsatisfactory feedback. This is mostly an aspect related to the = interaction between the IESG and the IAB about when and how many WGs = with a rather long-term workscope should be created. QoS is rather a = long-term project, I would argue.=20 Ciao Hannes PS: I would also like to point to the fact that we also started the = Diameter QoS work in NSIS that has, interestingly enough, gained more = attraction in the industry. This work has finally found a home in the = DIME working group and we are seen interesting thoughts how to harmonize = the different flavors being developed by various organizations.=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 17 11:10:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNel-0007q3-Tr; Wed, 17 May 2006 11:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNek-0007pQ-Oh for architecture-discuss@ietf.org; Wed, 17 May 2006 11:09:46 -0400 Received: from smtp6-g19.free.fr ([212.27.42.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNei-0006JJ-1z for architecture-discuss@ietf.org; Wed, 17 May 2006 11:09:46 -0400 Received: from asus.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp6-g19.free.fr (Postfix) with ESMTP id 9A9532256D for ; Wed, 17 May 2006 17:09:39 +0200 (CEST) Message-Id: <7.0.1.0.2.20060517170111.01ce3830@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 17 May 2006 17:09:18 +0200 To: architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Subject: [arch-d] need to deprecate the root servers system? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0220003540==" Errors-To: architecture-discuss-bounces@ietf.org --===============0220003540== Content-Type: multipart/alternative; boundary="=====================_6347703==.ALT" --=====================_6347703==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable I sent the following mail on the ietf@ietf.org mailing list. The=20 question it raises has been subsequently discussed on various lists.=20 My intent is not to initiate a debate on the matter. It is more to=20 register a position for further reference and thinking, if the work I=20 have engaged, other similar ones, or user practices calls for them. I=20 am fully aware of the IETF hysteresys: at leas the IETF and the IAB=20 will have been informed. ---------- The way in which the IDNs are (not) supported and the resulting=20 increase of other local and lingual naming solutions (keywords,=20 aliases, externets, such as China) lead to the idea that in the near=20 future the adopted name resolutions solutions with the largest=20 development potential will not use data that are obtained from the=20 root server system (RSS). Without considering political orientation, many indications are going=20 into that direction. * keywords have demonstrated uniqueness in name and destination=20 is not necessary for predictability. * its seems that the impact of typos on new longer and=20 diversified TLD has not been considered. * the complexity of schemes reversing the level order may allow=20 for new systems * the WIPO position, not to address ACE cybersquatting, may call=20 for new solutions. * different "patch" level for ISPs; for keywords, foreign names,=20 and aliases =96 with private strategies * two/tiers internet various solutions * the probable use of OPES/ONES (OPES coordinated networks)=20 solutions in naming. * the lack of flexibility of a global RSS to address local=20 situations and demands; * Justice and intelligence protection calling for local logs. * anti-pharming protection * individual nameservers with full local root capacity * low number of root file updates * etc. I have observed that many problems could be solved or would be easier=20 to solve - either directly or due to the necessary replacement=20 practices - if the root server system was deprecated. The RSS helped=20 in the maintenance and development of a naming stability culture.=20 Nevertheless, it now seems [when the Internet must deliver what it=20 was not designed for] to be fighting against its purpose. My=20 conclusion may be wrong, but I think a debate is necessary. US interests are to be protected: this is achieved by the=20 ftp://rs.internet.net file as the NTIA=20 authoritative file for the Internationalised US Internet agreed in=20 Tunis. However, others would like their interests to also be=20 respected. If the rigidity of the system leads to conflict, we will=20 arrive at network fragmentation. I had a difficult time (IDNA and RFC 3066 Bis) ensuring that there=20 would be some possible interoperability maintained between the=20 Internationalised US Internet and the Multilingual International=20 Network, even if most of those at the IETF do not see the differences=20 between these two systems. IMHO now is the last chance that we have=20 to avoid a split instead of a single Multilingual Internet. Let=20 consider that in a global network, we all are bound together. There=20 is no win/lose situation. There are only win/win and lose/lose ones. I am certain that most Multilingual Internet projects will be ready=20 to cooperate with an IETF/ICANN effort and will seriously consider=20 them. I have pled for years for an ITU-I interface for the=20 Intelligent Networks needs with the ITU. I also propose the creation=20 of an IGFTF entity in order to welcome the IGF concerns and ethic=20 within the Internet standard process. Therefore, I will have an attempt once more, at least for the=20 records. Calling for: * the IESG to respect the RFC 3066 Bis consensus. * the IETF to work on the internationalisation and=20 multilingualisation layers. * all of us to engage in a debate about the deprecation of the=20 old loyal root server system. * work on multi-authoritative issues through intrinsic support,=20 and not as mono-authoritative options. jfc _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --=====================_6347703==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I sent the following mail on the ietf@ietf.org mailing list. The question it raises has been subsequently discussed on various lists. My intent is not to initiate a debate on the matter. It is more to register a position for further reference and thinking, if the work I have engaged, other similar ones, or user practices calls for them. I am fully aware of the IETF hysteresys: at leas the IETF and the IAB will have been informed.

----------

The way in which the IDNs are (not) supported and the resulting increase of other local and lingual naming solutions (keywords, aliases, externets, such as China) lead to the idea that in the near future the adopted name resolutions solutions with the largest development potential will not use data that are obtained from the root server system (RSS).

Without considering political orientation, many indications are going into that direction.=20
  • keywords have demonstrated uniqueness in name and destination is not necessary for predictability.=20
  • its seems that the impact of typos on new longer and diversified TLD has not been considered.=20
  • the complexity of schemes reversing the level order may allow for new systems=20
  • the WIPO position, not to address ACE cybersquatting, may call for new solutions.=20
  • different =93patch=94 level for ISPs; for keywords, foreign names, an= d aliases =96 with private strategies=20
  • two/tiers internet various solutions=20
  • the probable use of OPES/ONES (OPES coordinated networks) solutions in naming.=20
  • the lack of flexibility of a global RSS to address loc= al situations and demands;=20
  • Justice and intelligence protection calling for local logs.=20
  • anti-pharming protection=20
  • individual nameservers with full local root capacity=20
  • low number of root file updates=20
  • etc.=20
I have observed that many problems could be solved or would be easier to solve - either directly or due to the necessary replacement practices - if the root server system was deprecated. The RSS helped in the maintenance and development of a naming stability culture. Nevertheless, it now seems [when the Internet must deliver what it was not designed for] to be fighting against its purpose. My conclusion may be wrong, but I think a debate is necessary.

US interests are to be protected: this is achieved by the ftp://rs.internet.net file as the NTIA authoritative file for the Internationalised US Internet agreed in Tunis. However, others would like their interests to also be respected. If the rigidity of the system leads to conflict, we will arrive at network fragmentation.

I had a difficult time (IDNA and RFC 3066 Bis) ensuring that there would be some possible interoperability maintained between the Internationalised US Internet and the Multilingual International Network, even if most of those at the IETF do not see the differences between these two systems. IMHO now is the last chance that we have to avoid a split instead of a single Multilingual Internet. Let consider that in a global network, we all are bound together. There is no win/lose situation. There are only win/win and lose/lose ones.

I am certain that most Multilingual Internet projects will be ready to cooperate with an IETF/ICANN effort and will seriously consider them. I have pled for years for an ITU-I interface for the Intelligent Networks needs with the ITU. I also propose the creation of an IGFTF entity in order to welcome the IGF concerns and ethic within the Internet standard process.


Therefore, I will have an attempt once more, at least for the records. Calling for:=20
  1. the IESG to respect the RFC 3066 Bis consensus.=20
  2. the IETF to work on the internationalisation and multilingualisation layers.=20
  3. all of us to engage in a debate about the deprecation = of the old loyal root server system.=20
  4. work on multi-authoritative issues through intrinsic support, and not as mono-authoritative options.=20
jfc
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
 --=====================_6347703==.ALT-- --===============0220003540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0220003540==-- From architecture-discuss-bounces@ietf.org Wed May 17 19:21:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVJD-0006hz-8n; Wed, 17 May 2006 19:20:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVJC-0006gG-Df for architecture-discuss@ietf.org; Wed, 17 May 2006 19:20:02 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVJB-0001er-3y for architecture-discuss@ietf.org; Wed, 17 May 2006 19:20:02 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA01796; Wed, 17 May 2006 16:19:46 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4HNJmr22184; Wed, 17 May 2006 16:19:48 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 16:19:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Wed, 17 May 2006 16:19:07 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108025848B1@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjAAeqS+gABjvJUA= From: "Fleischman, Eric" To: "Tschofenig, Hannes" , X-OriginalArrivalTime: 17 May 2006 23:19:46.0540 (UTC) FILETIME=[62F83AC0:01C67A08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 >> Anyway, when I read the NSIS material, I can't escape the feeling that=20 >> these people have a telephony mentality. >What do you consider "telephony mentality" when you read about the NSIS work?=20 When I seek to integrate non-Internet technologies with IP, I first try to entirely replace them with IP only technologies. If that isn't possible, then I encapsulate them within IP so that they could use the Internet via RFC 1001, 1002, and 1006-like mechanisms. Failing that, I interpose application layer translation gateways. The latter is always my last choice because of the operational difficulty we have experienced in maintaining these gateways historically, with significant performance and scaling implications. When I read the NSIS work, I believe that I am seeing a body that is trying to link POTS or similar legacy technology systems with IP as if they are equals. Specifically, I imagine that I am seeing a group that is trying to add signaling semantics to IP networks to support integration with telephony ideas and constructs. However, your email stated that I am not viewing this correctly, which means that I need to re-read that material. >From where I sit, the approach of adding state to the IP layer has proven to be damaging to IP networks and systems. I rather recommend that the applications themselves become modified to work in stateless IP environments, if possible. For voice and video, this may include adding extensive error correction techniques but definitely means re-writing the codecs themselves to address IP realities.=20 I also recognize a class of applications that aren't likely to work well over the Internet. What we need to better support them is stochastic access with deterministic trunking. It may be that Diff-Serv with MPLS can achieve this, or maybe it can't. I just don't know. I started this thread to learn, not to preach. What insights can you offer me? One lesson we learned during the 80s from the OSI debacle is that mixing resource-reservation lower layers over a CONS-like network layer with best-effort CLNS network layers just don't work. The infrastructure either needs to be CONS or CLNS -- mixing them is A Bad Thing. --Eric _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 17 19:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVZb-0007NX-Rv; Wed, 17 May 2006 19:36:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVZa-0007NR-SC for architecture-discuss@ietf.org; Wed, 17 May 2006 19:36:58 -0400 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FgVZZ-0002f5-Cz for architecture-discuss@ietf.org; Wed, 17 May 2006 19:36:58 -0400 Received: from webmail50.lax.untd.com (webmail50.lax.untd.com [10.131.27.190]) by smtpout06.lax.untd.com with SMTP id AABCGZN5YAN5E2VJ for (sender ); Wed, 17 May 2006 16:36:22 -0700 (PDT) Received: (from fergdawg@netzero.net) by webmail50.lax.untd.com (jqueuemail) id LQL2B6GD; Wed, 17 May 2006 16:35:40 PDT Received: from [71.145.128.177] by webmail50.lax.untd.com with HTTP: Wed, 17 May 2006 23:34:45 GMT X-Originating-IP: [71.145.128.177] Mime-Version: 1.0 From: "Fergie" Date: Wed, 17 May 2006 23:34:45 GMT To: eric.fleischman@boeing.com Subject: RE: [arch-d] QoS Signaling Status and Support X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20060517.163540.13636.1250472@webmail50.lax.untd.com> X-ContentStamp: 10:5:2788754878 X-MAIL-INFO: 5ec139b489893989e17039b5b57029bdbdb17515bdf561500400302535202054d0818db4 X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPdRgN+zfreIHn6EhbQRvFTlew+Ukj8p1SQ== X-UNTD-Peer-Info: 10.131.27.190|webmail50.lax.untd.com|webmail50.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: architecture-discuss@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bell-shaped heads, that what we used to call them. ;-) No offense intended. :-) Back to the topic at hand: I firmly believe that we have the building blocks, in diff-serv, to actually do the things we talk about, and make end-to-end service levels a reality. The problem, unfortunately, is not a technical one -- it is politics in its most base form. And within the Internet that we know _today_, we cannot get around that hurdle at the moment. - ferg -- "Fleischman, Eric" wrote: [snip] I also recognize a class of applications that aren't likely to work well= over the Internet. What we need to better support them is stochastic access with deterministic trunking. It may be that Diff-Serv with MPLS can achieve this, or maybe it can't. I just don't know. I started this thread to learn, not to preach. What insights can you offer me? One lesson we learned during the 80s from the OSI debacle is that mixing= resource-reservation lower layers over a CONS-like network layer with best-effort CLNS network layers just don't work. The infrastructure either needs to be CONS or CLNS -- mixing them is A Bad Thing. --Eric -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 17 19:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVkp-0003vD-Nm; Wed, 17 May 2006 19:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVko-0003v8-8R for architecture-discuss@ietf.org; Wed, 17 May 2006 19:48:34 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVkm-0003NV-Rx for architecture-discuss@ietf.org; Wed, 17 May 2006 19:48:34 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4HNliV04006; Wed, 17 May 2006 16:47:44 -0700 (PDT) Message-ID: <446BB620.50605@isi.edu> Date: Wed, 17 May 2006 16:47:44 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Fleischman, Eric" Subject: Re: [arch-d] QoS Signaling Status and Support References: <474EEBD229DF754FB83D256004D02108025848B1@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D02108025848B1@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: architecture-discuss@ietf.org, "Tschofenig, Hannes" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fleischman, Eric wrote: > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >>> Anyway, when I read the NSIS material, I can't escape the feeling > that >>> these people have a telephony mentality. > >> What do you consider "telephony mentality" when you read about the NSIS > work? > > When I seek to integrate non-Internet technologies with IP, I first try > to entirely replace them with IP only technologies. If that isn't > possible, then I encapsulate them within IP so that they could use the > Internet via RFC 1001, 1002, and 1006-like mechanisms. Failing that, I > interpose application layer translation gateways. The latter is always > my last choice because of the operational difficulty we have experienced > in maintaining these gateways historically, with significant performance > and scaling implications. Internet - degrades gracefully with additional traffic. Avoids global state; typically relies on local state with local decisions. Telephony - performs call admission to limit to a finite number of users each receiving a sufficient level of service; rejects calls beyond that. Requires global state and coordination. There are those who treat Internet and telephony like MPI and shared memory - duals that can be interchanged. While it's trivial to build an Internet on top of a telephone system (that's how it's typically done), the converse is nonsensical. Adding state and call admission to the Internet means that local state / decisions won't suffice, and that graceful degradation won't result. > The infrastructure > either needs to be CONS or CLNS -- mixing them is A Bad Thing. And layering them doesn't work (at least in one direction) either. ;-) Joe _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed May 17 20:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWgi-0003W3-0W; Wed, 17 May 2006 20:48:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWgg-0003Vw-Kd for architecture-discuss@ietf.org; Wed, 17 May 2006 20:48:22 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWgf-0006Bd-Dx for architecture-discuss@ietf.org; Wed, 17 May 2006 20:48:22 -0400 Received: from [10.0.1.32] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <20060518004820014005edcde>; Thu, 18 May 2006 00:48:20 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <474EEBD229DF754FB83D256004D02108025848B1@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D02108025848B1@XCH-NW-6V1.nw.nos.boeing.com> Date: Wed, 17 May 2006 20:39:07 -0400 To: "Fleischman, Eric" , "Tschofenig, Hannes" , From: John Day Subject: RE: [arch-d] QoS Signaling Status and Support Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > >One lesson we learned during the 80s from the OSI debacle is that mixing >resource-reservation lower layers over a CONS-like network layer with >best-effort CLNS network layers just don't work. The infrastructure >either needs to be CONS or CLNS -- mixing them is A Bad Thing. Just for the record, OSI never attempted such a solution and in fact I don't believe it really ever considered it. All it did was attempt to legislate their separation. (OSI should never invited the phone companies to the party, but it is doubtful the Europeans could have not invited them. The only real lesson learned from the OSI debacle is that if you are doing a new architecture, don't invite the legacy one to join.) Actually as already pointed out, the ARPANet was more CONS than CNLS for most of its life. Also it was very likely that the connection nature of BBN 1822 and the use of X.25 as its replacement that forestalled the congestion collapse as long as it did. Now that said, I think the CONS advocates have done a pretty lousy job of understanding how it can/should be used. They seemed to be as locked in their religion as the CLNS advocates are in theirs. We have seen one engineering hack proposed after another. I have seen no real attempt in the last 35 years to really understand what is going on with CO and CL. All I have seen are two warring factions with the strong belief that the thing they are currently working on will spell the demise of the other. At this point, it should be clear that neither is going to happen. That should tell us that there is something about this that we don't yet get. But so far all I hear on this list is how sure we are of what we know. Given how little science we have to base that on, it should give us considerable pause. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 02:36:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc69-0002JK-C6; Thu, 18 May 2006 02:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc68-0002JF-GO for architecture-discuss@ietf.org; Thu, 18 May 2006 02:35:00 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgc66-0001Fw-To for architecture-discuss@ietf.org; Thu, 18 May 2006 02:35:00 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 17 May 2006 23:34:58 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k4I6YwQd002453; Wed, 17 May 2006 23:34:58 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4I6YvJj024140; Wed, 17 May 2006 23:34:57 -0700 (PDT) Received: from [193.204.93.24] (ams3-vpn-dhcp328.cisco.com [10.61.65.72]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4I6WOdv005720; Wed, 17 May 2006 23:32:24 -0700 In-Reply-To: References: <474EEBD229DF754FB83D256004D02108025848A8@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 08:34:55 +0200 To: Pekka Savola , Eric Fleischman , Tony Li X-Mailer: Apple Mail (2.749.3) Authentication-Results: sj-dkim-6.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=6195; t=1147934098; x=1148798098; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20QoS=20Signaling=20Status=20and=20Support; X=v=3Dcisco.com=3B=20h=3Dq082b8V4cIuRdTM61eWez+Wj74U=3D; b=YMCwKnEzvx697uoYWp7n0ECvACi0jilMSK6QLa27LaWpNB74Moq0YLuhjbrG0Bs+wCV5lzzo sahtJmD9LxNJLo+qNT6SoWhw1TzORzrVUIdwaEhHGOUUg/UTkecIDMkQ; X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On May 17, 2006, at 6:20 AM, Pekka Savola wrote: > The thinking seems to go like this: "IntServ using RSVP was not > succesful.. so the fault must have been at RSVP. Let's design a > better version of RSVP!" OK, so let me ask what must be a dumb question. What was in fact the problem? The problem that int-serv went out to solve is one that we increasingly find ourselves needing to solve in the commercial backbone, says the guy who met yesterday and has been meeting for quite a while with half a dozen phone-mobile-and-internet companies and several government agencies, all of whose names you would recognize, who are looking at exactly this issue. There is a set of applications whose defining characteristics include the fact that they send data at something resembling a fixed rate. The archetypal ones are voice and video of various types, but these also including telemetry feeds and related sensor applications. The "fixed" speed may be variable-within-a-range, there may be a way for the codec to select one of several speeds or speed ranges, and in some cases, the codec may be silent for periods of time. However, when transmitting there are a minimum and a maximum rate in any case. The list of these applications include unidirectional, bidirectional, and multicast versions. In order to reliably deliver a certain QoS, I have to know how much is in the network; if the application cannot or will not adapt, I am forced to limit the number of instances of it in the network to maintain an SLA. Internet Routing does not route circuits/LSPs/microflows/whatever-you- want-to-call-them at the IP layer, so we don't have that option available to us for solving this. Measurement-based admission techniques performed in the end system can be helpful in places where the law of large numbers applies, but are of limited utility on slower links, and in any event from a provider perspective require trusting the host to do the right thing for the network. They have significant problems: past performance, to quote the people that want to sell me stocks, is not a good predictor of future performance. Even if changes in routing that dump engineered data streams into a common hopper are not a real problem, the probing involved in measurement-based techniques like Briscoe is suggesting can itself be a denial of service attack, and doesn't allow for provider implementation of policies like MLPP or its civilian counterpart. If one discards path-coupled control plane protocols, that doesn't leave a lot of choices. Absent a mechanism that can dynamically ask the network whether critical points have a certain capability, we do it by static engineering, whether done in network planning or in MPLS-TE and related approaches. Sometimes that is the right approach; I am working with an astronomer at Swinburne University on a matter related to a telemetry feed, and for an 8 GBPS data flow deriving from a 512 MHz A/D conversion, a lambda is a wonderful solution. In the kinds of networks that you, Eric, are working on these days, manual engineering of data flows is a suboptimal solution I should think, and yes you know exactly the types of telemetry and video feeds and session management policies to which I refer. Int-Serv gives the network the ability to know what its parameters are for these protocols and the ability to say "no" in a manner consistent with a management policy that may differentiate between sessions of different categories with different thresholds. By "parameters", I mean statements of the form "the sum of the codecs-or- etc using this class right now is , could burst to at any time, and could conceivably sustain that". I'm quite happy to be told that I am in denial if it can be shown. Nevertheless, I have a set of people who find themselves stuck between the proverbial rock and hard place. Their applications have limited ability to adapt to the network, they are required (in some cases by the local equivalent of law) to implement network policies that differentiate in the network between different sessions, and they have commercial requirements both to deploy the services and to not permit new calls to unnecessarily disrupt existing calls. If infinite* bandwidth is not available or is costly, and asking the network at bottlenecks to state whether it currently has available capacity to accomplish a stated goal is off limits, and end system measurement fails to reliably deliver the goods, what would you suggest? Since we are the ones in denial, you must have a constructive suggestion in mind that we are overlooking. If you don't, then I submit that it is at least possible that I am not the one in denial. By the way, the assertion that NSIS is in fact a better protocol than RSVP is at this point unproven. It is probably not worse (although it is in fact two protocols where RSVP has one, which in my opinion is a debatable call). I don't see any proofs on the table that it is across-the-board better. It is mostly different, and from the perspective of RFC 4542, incomplete. * - "Infinite bandwidth", as I use the term, is "sufficient bandwidth that traffic inter-arrival jitter is nominal compared to the requirements of any current application or transport and congestion- related loss is negligible along the entire path or set of paths in question". ISPs in the "lit" portion of the world routinely deliver core networks that have this characteristic; it is not necessarily a characteristic of access paths, or of network types that are not easily implemented using fiber (see http://www.skyimagelab.com/ earatnitlar.html for a notion of what parts of the world are "lit" and "unlit", but note that network edges are often bandwidth limited even in the "lit" world). Answers of the form "the core of my network has infinite bandwidth under that definition" are non-responsive to the question from an end-to-end perspective. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 02:57:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgcRy-0002iK-DN; Thu, 18 May 2006 02:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgcRx-0002gc-PJ for architecture-discuss@ietf.org; Thu, 18 May 2006 02:57:33 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgcRw-0002U0-Ag for architecture-discuss@ietf.org; Thu, 18 May 2006 02:57:33 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I6vRiO020418; Thu, 18 May 2006 09:57:27 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 09:57:26 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 09:57:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 09:57:25 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C442@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6Rch7VllWvS23TjySkR2RsWrtfQAAQ7HQ From: To: , , , X-OriginalArrivalTime: 18 May 2006 06:57:26.0590 (UTC) FILETIME=[526F55E0:01C67A48] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Fred, >On May 17, 2006, at 6:20 AM, Pekka Savola wrote: >> The thinking seems to go like this: "IntServ using RSVP was not=20 >> succesful.. so the fault must have been at RSVP. Let's design a=20 >> better version of RSVP!" > >OK, so let me ask what must be a dumb question. What was in=20 >fact the problem? Thanks for the question. When we were talking with Scott & Allison about NSIS, the problem basis was two-fold: 1) There's a lot of transparent entities on the Internet that effect the treatment of packets - NATs, FWs, admission control boxes, etc. It would be good to be able to allow the the end node to be able to signal these entities, as these transparent entities cause a lot of trouble. 2) The IETF has spent a lot of energy on QoS - IntServ (CL, Guarenteed Service) and DiffServ - but there has been a general feeling=20 that more needs to be done to enable some services and deployments. A lot of other SDOs are specifying QoS and planning on deploying their QoS over the Internet. Having a general signaling mechanism to signal IETF QoS (IntServ, DiffServ) as well as having a framework for other groups to signal their QoS over the Internet could be a good=20 thing. At a high-level, this MAY promote some level of interoperability. Since kicking that work off, there has been some other issues that=20 have come up, but I'll get to that in a separate mail. However, to respond to Pekka's comment: >> The thinking seems to go like this: "IntServ using RSVP was not=20 >> succesful.. so the fault must have been at RSVP. Let's design a=20 >> better version of RSVP!" Not exactly - the thinking was the tight coupling of RSVP with IntServ has created some problems, so it might be good to=20 try to decouple them. RSVP-TE works quite well, so I don't think that RSVP is the problem. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 03:09:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgcdR-00079n-VE; Thu, 18 May 2006 03:09:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgcdQ-00079H-Tx for architecture-discuss@ietf.org; Thu, 18 May 2006 03:09:24 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgcdN-00038X-BJ for architecture-discuss@ietf.org; Thu, 18 May 2006 03:09:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I79Fdg024628; Thu, 18 May 2006 10:09:17 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:09:15 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:09:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 10:09:14 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C443@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6Rch7VllWvS23TjySkR2RsWrtfQAAozkA From: To: , , , X-OriginalArrivalTime: 18 May 2006 07:09:15.0175 (UTC) FILETIME=[F8C8D370:01C67A49] X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Further responses in-line. >The problem that int-serv went out to solve is one that we=20 >increasingly find ourselves needing to solve in the commercial=20 >backbone, says the guy who met yesterday and has been meeting=20 >for quite a while with half a dozen phone-mobile-and-internet=20 >companies and several government agencies, all of whose names=20 >you would recognize, who are looking at exactly this issue.=20 >There is a set of applications whose defining characteristics=20 >include the fact that they send data at something resembling a=20 >fixed rate. The archetypal ones are voice and video of various=20 >types, but these also including telemetry feeds and related=20 >sensor applications. The "fixed" speed may be=20 >variable-within-a-range, there may be a way for the codec to=20 >select one of several speeds or speed ranges, and in some=20 >cases, the codec may be silent for periods of time. However,=20 >when transmitting there are a minimum and a maximum rate in=20 >any case. The list of these applications include=20 >unidirectional, bidirectional, and multicast versions. In=20 >order to reliably deliver a certain QoS, I have to know how=20 >much is in the network; if the application cannot or will not=20 >adapt, I am forced to limit the number of instances of it in=20 >the network to maintain an SLA. I agree with the above scenario - but also a small tweak -=20 some applications can adapt to smaller pipe, but they behave best if they have some rough constraints, in that case,=20 the rates can change, but the goal is to have the change more slowly, in order to be able to adapt or switch codecs. >Internet Routing does not route circuits/LSPs/microflows/whatever-you- >want-to-call-them at the IP layer, so we don't have that=20 >option available to us for solving this. Measurement-based=20 >admission techniques performed in the end system can be=20 >helpful in places where the law of large numbers applies, but=20 >are of limited utility on slower links, and in any event from=20 >a provider perspective require trusting the host to do the=20 >right thing for the network. They have significant problems:=20 >past performance, to quote the people that want to sell me=20 >stocks, is not a good predictor of future performance. =20 >Even if changes in routing that dump engineered data streams=20 >into a common hopper are not a real problem, the probing=20 >involved in measurement-based techniques like Briscoe is=20 >suggesting can itself be a denial of service attack, and=20 >doesn't allow for provider implementation of policies like=20 >MLPP or its civilian counterpart. If one discards path-coupled=20 >control plane protocols, that doesn't leave a lot of choices. Agreed, I also have been hearing more of a need from different service providers that having a general mechanism to have interdomain solutions - measurement-based admission control is OK in a single domain - but from an end-to-end or interdomain deployment, the results are far less satisfying.=20 [Editing out the stuff that I agree with] >By the way, the assertion that NSIS is in fact a better=20 >protocol than RSVP is at this point unproven. It is probably=20 >not worse (although it is in fact two protocols where RSVP has=20 >one, which in my opinion is a debatable call). I don't see any=20 >proofs on the table that it is across-the-board better. It is=20 >mostly different, and from the perspective of RFC 4542, incomplete. The goal is to try to overcome some of the current shortcomings in the RSVP + IntServ approach. There is on-going work in using IntServ QoS over NSIS signaling, which looks like it should work quite well. Some early tests, using well-known RSVP implementations have shown that a few NSIS implementations scale a bit better that RSVP, at around 60k sessions, if I remember right. I think there is some published=20 results about this, that I could post a link to if anyone is interested. Anyhow, I'd probably stay away from 'better protocol' at the moment, as I generally tend to see what NSIS is doing is trying to make some additional tools to allow better signaling across the Internet, especially when different deployments models are traversed. John If anyone is interested, I'd thought I'd plug a couple of implementations, that people could check out. =09 http://nsis.dei.uc.pt/ http://user.informatik.uni-goettingen.de/~nsis/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 03:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgcjl-0001Zt-VC; Thu, 18 May 2006 03:15:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgcjl-0001Zo-0g for architecture-discuss@ietf.org; Thu, 18 May 2006 03:15:57 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgcjj-0003S6-Hj for architecture-discuss@ietf.org; Thu, 18 May 2006 03:15:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I7Fp9k022395; Thu, 18 May 2006 10:15:53 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:15:26 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:15:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 10:15:22 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C444@esebe100.NOE.Nokia.com> In-Reply-To: <20060517.163540.13636.1250472@webmail50.lax.untd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6CuXB9peNUQLaSW2eqtvtmJt+nAAPxcmg From: To: , X-OriginalArrivalTime: 18 May 2006 07:15:22.0974 (UTC) FILETIME=[D4027FE0:01C67A4A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: architecture-discuss@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Ferg, >Bell-shaped heads, that what we used to call them. ;-) > >No offense intended. :-) Not really sure that the above helps. If you look at the current state of the Internet, with consolidation of ISPs, backbone carriers, telcos and mobile nets - the clear division between bell heads and net heads is gone. Heck, SCTP has been discussed on this list as a potential new way of doing things, but SCTP was originally designed to carry SS7 over IP. >Back to the topic at hand: > >I firmly believe that we have the building blocks, in=20 >diff-serv, to actually do the things we talk about, and make=20 >end-to-end service levels a reality. RFC2996 does allow you to use RSVP to signal DiffServ end-to-end, but AFAIK, it isn't widely deployed. DiffServ is not designed to be end-to-end, so I think we need to be able to tie things up on an end-to-end basis. >The problem, unfortunately, is not a technical one -- it is=20 >politics in its most base form. And within the Internet that=20 >we know _today_, we cannot get around that hurdle at the moment. What level of politics do you mean? Net Neutrality type of politics, SDO level of politics (different SDOs defining very different QoS solutions), or something else. thanks, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 03:23:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgcr1-0003Z4-UH; Thu, 18 May 2006 03:23:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgcr0-0003Yz-MM for architecture-discuss@ietf.org; Thu, 18 May 2006 03:23:26 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgcr0-0003lm-8J for architecture-discuss@ietf.org; Thu, 18 May 2006 03:23:26 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I7NMai026075; Thu, 18 May 2006 10:23:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:22:39 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:22:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 10:22:38 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C445@esebe100.NOE.Nokia.com> In-Reply-To: <474EEBD229DF754FB83D256004D02108025848B1@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjAAeqS+gABjvJUAAEc3NsA== From: To: , , X-OriginalArrivalTime: 18 May 2006 07:22:39.0246 (UTC) FILETIME=[D80C52E0:01C67A4B] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Eric, >When I read the NSIS work, I believe that I am seeing a body=20 >that is trying to link POTS or similar legacy technology=20 >systems with IP as if they are equals. Specifically, I imagine=20 >that I am seeing a group that is trying to add signaling=20 >semantics to IP networks to support integration with telephony=20 >ideas and constructs. However, your email stated that I am not=20 >viewing this correctly, which means that I need to re-read=20 >that material. I will definitely agree that many of the people bringing requirements to NSIS are coming from a telco deployment mindset. AFAIK, the goal isn't strict interworking with POTS, but how they can move their networks to be fully IP based. However, for many of=20 service providers, their value proposition to their customers is a very high-level commitment to quality - in terms of=20 predicability (roughly same level of service provided); good session setup time; high service availability. Additionally, many of these deployments have SLA agreements with other companies and they are looking for solutions on how to tie these things together. >>From where I sit, the approach of adding state to the IP layer has >proven to be damaging to IP networks and systems. I rather=20 >recommend that the applications themselves become modified to=20 >work in stateless IP environments, if possible. For voice and=20 >video, this may include adding extensive error correction=20 >techniques but definitely means re-writing the codecs=20 >themselves to address IP realities.=20 > >I also recognize a class of applications that aren't likely to=20 >work well over the Internet. What we need to better support=20 >them is stochastic access with deterministic trunking. It may=20 >be that Diff-Serv with MPLS can achieve this, or maybe it=20 >can't. I just don't know. I started this thread to learn, not=20 >to preach. What insights can you offer me? I think that this is what a lot of folks are doing, but there=20 are issues when looking at this end-to-end, across different network providers, or at least that's what people are telling me. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 03:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgcwJ-0005vU-LB; Thu, 18 May 2006 03:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgcwI-0005vP-Iy for architecture-discuss@ietf.org; Thu, 18 May 2006 03:28:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgcwI-00044n-HF for architecture-discuss@ietf.org; Thu, 18 May 2006 03:28:54 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgcwI-0007lm-0b for architecture-discuss@ietf.org; Thu, 18 May 2006 03:28:54 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I7SnTg013748; Thu, 18 May 2006 10:28:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:28:36 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:28:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 10:28:35 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C446@esebe100.NOE.Nokia.com> In-Reply-To: <474EEBD229DF754FB83D256004D02108025848A9@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjAAAILhgAABwF4AASRqqIA== From: To: , , X-OriginalArrivalTime: 18 May 2006 07:28:35.0170 (UTC) FILETIME=[AC320420:01C67A4C] X-Spam-Score: -2.3 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Eric, >Question: Why does MPLS have success stories like this when=20 >Int-Serv didn't? Or does it? What do you think? My (cynical) feeling is that if you give tools to people who are running and maintaining networks that feel like something that they are familiar with, they are always more happy than with tools that are wildly different. =20 John When Internet access came to all employees at a place I was working at, NATs provided a great way for the sysadmins to deploy connectivity, as it looked like how they deployed T1 lines to interconnect different office networks between remote sites, so they thought that NATs were perfect for them. =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 03:48:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdEM-0002qH-7Z; Thu, 18 May 2006 03:47:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdEL-0002oG-17 for architecture-discuss@ietf.org; Thu, 18 May 2006 03:47:33 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgdEK-00065k-If for architecture-discuss@ietf.org; Thu, 18 May 2006 03:47:33 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I7lQ1t020198; Thu, 18 May 2006 10:47:29 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:47:28 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:47:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 10:47:26 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C447@esebe100.NOE.Nokia.com> In-Reply-To: <474EEBD229DF754FB83D256004D02108025848A8@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ5JUxZvuWfezsgQmems20v4U4JjABJ4Dpw From: To: , X-OriginalArrivalTime: 18 May 2006 07:47:26.0721 (UTC) FILETIME=[4EA6FF10:01C67A4F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Eric, >How well accepted is the NSIS work within the IETF? For=20 >example, I note that their RFCs that I have read were all=20 >experimental and that they point to other experimental work=20 >such as Seamoby. From this alone I surmise that it is not=20 >mainstream. Is this accurate? If so, then why is the IETF=20 >sponsoring their WG? Most importantly, how can their work fit=20 >into historic IP architectural models?=20 Actually, none of the RFCs are experimental - the protocol work is all standards track. There's no normative references to Seamoby - that stuff is all purely informative. There have been a couple of protocol interops that have been very successful - and a couple of open source implementations of the protocols, I sent links earlier. RSVP (especially in the -TE sense) is a very successful=20 protocol; but there are a number of issues with RSVP=20 and RSVP's extensibility that impact it's further use. I think Tony mentioned the issue about scalabililty for inter-domain use. =20 I don't see a lot of what NSIS is doing as being outside of standard IP architecture. Sure, some people might complain about different some of the different QoS models, but I view running different QoS models (ITU-T QoS models for example) over NSIS protocols as not being incompatible with historic IP=20 architecture models, like you said earlier, tunneling non-IP=20 traffic over IP is well accepted practice. For the NSIS QoS work, the driving goal is to be able to=20 signal IETF QoS models on an end-to-end basis; because of some deployment cases the signaling might have to be end-to- middle - but this is better than some other strategies, like having a box that sits inside of network, making QoS decisions for entity for the end hosts.=20 As a secondary goal of the QoS NSIS work, we want to be able to support other non-IETF QoS models, so that they can signal=20 their QoS over IP in an Internet-friendly way. Probably at a later date, we'll address how to interwork these different QoS regimes. I look at QoS signaling as more oportunistic than any thing else. If you and I deploy similar QoS in our networks, it would make sense to be able to signal this end-to-end; most likely the back bone shouldn't know or care about QoS, as much of the QoS-related bottlenecks happen in the local / access networks. If / when QoS is more widely deployed, my basic assumption is it will be tied more towards the network where you are accessing it=20 from, especially in the wireless domain. The implication is that there are some QoS islands at first, and opportunistically signaling some packet treatment in these islands could be useful, and being able to signal this to the other end would be good. Having a default Internet QoS mechanism seems like much more difficult issue, IMO. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 03:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdJO-0004nC-QO; Thu, 18 May 2006 03:52:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdJN-0004n7-0k for architecture-discuss@ietf.org; Thu, 18 May 2006 03:52:45 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgdJL-0006PA-Ia for architecture-discuss@ietf.org; Thu, 18 May 2006 03:52:44 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I7qbv0005807; Thu, 18 May 2006 10:52:41 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:51:44 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:51:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 10:51:43 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C448@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ5eyjKQOCESSE6TM2C8LI+IBL0HAA1DVfQ From: To: , X-OriginalArrivalTime: 18 May 2006 07:51:43.0304 (UTC) FILETIME=[E7967480:01C67A4F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka, >> A few years back I started a thread on the ietf mailing list asking=20 >> about the current state of RSVP, and I received a lot of feedback from=20 >> IETF participants about how valuable RSVP-TE was proving to=20 >be for MPLS. > >I remember that discussion because I remember criticizing=20 >path-coupled signalling approaches :-) I remember as well, but the idea of having having the network do this on an end-node's behalf seems a bit wonky to me, especially if you deploy it as some type of QoS oracle box that knows exactly what is going on in the network and makes decisions based upon that.=20 If I remember correctly, you were suggesting a bandwidth broker style approach, but I don't really see how to do end-to-end with such boxes, outside of limited deployments. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 04:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdtZ-0002kY-Im; Thu, 18 May 2006 04:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdtY-0002kT-AV for architecture-discuss@ietf.org; Thu, 18 May 2006 04:30:08 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgdtW-0000MV-SI for architecture-discuss@ietf.org; Thu, 18 May 2006 04:30:08 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I8U24j024170; Thu, 18 May 2006 11:30:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 11:30:02 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 11:30:01 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 11:30:01 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6RclA+BypAvpoSImE/XsZvGNVlgADth0g From: To: , , , X-OriginalArrivalTime: 18 May 2006 08:30:01.0817 (UTC) FILETIME=[419BB490:01C67A55] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred Baker wrote: ... >I'm quite happy to be told that I am in denial if it can be shown. =20 ... > asking=20 >the network at bottlenecks to state whether it currently has=20 >available capacity to accomplish a stated goal is off limits,=20 ... Isn't IntServ style QoS reservation equivalent to this? If this is off limits, are you saying there is nothing that can be done? Jarno _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 06:03:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfKL-0008Ku-WC; Thu, 18 May 2006 06:01:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfKK-0008Kp-Vt for architecture-discuss@ietf.org; Thu, 18 May 2006 06:01:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgfKI-0004QZ-MU for architecture-discuss@ietf.org; Thu, 18 May 2006 06:01:52 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 18 May 2006 03:01:50 -0700 X-IronPort-AV: i="4.05,140,1146466800"; d="scan'208"; a="278808673:sNHT32067824" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4IA1nIj023111 for ; Thu, 18 May 2006 03:01:49 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4IA1nB7028746 for ; Thu, 18 May 2006 03:01:49 -0700 (PDT) Received: from [193.204.93.24] (ams3-vpn-dhcp229.cisco.com [10.61.64.229]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4I9xGpo010328 for ; Thu, 18 May 2006 02:59:17 -0700 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63C2797E-7658-4DC1-8083-13843BC8C45F@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 12:01:48 +0200 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.749.3) Authentication-Results: sj-dkim-1.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1275; t=1147946509; x=1148810509; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20QoS=20Signaling=20Status=20and=20Support; X=v=3Dcisco.com=3B=20h=3Dahpy6l4rY6tk73CXZMgJKdTY1wg=3D; b=BwmkCAdU3/mvqrmMkdDfR69Me0j4VXIZfAW1OHS41deuTFuLUeW49LPGR2e/VX0opTjicAC2 9LhLx38LxeSMx7/tyJ05ec5Zp7S/04o2NEGqKt7X3z6agNbbyGCsnsli; X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On May 18, 2006, at 10:30 AM, wrote: > Fred Baker wrote: > ... >> I'm quite happy to be told that I am in denial if it can be shown. > ... >> asking the network at bottlenecks to state whether it currently >> has available capacity to accomplish a stated goal is off limits, > ... > > Isn't IntServ style QoS reservation equivalent to this? If this is off > limits, are you saying there is nothing that can be done? Integrated Services, aka NSIS or RSVP equivalently and presumably other protocols if one wants to build them, allows a bottleneck interface in the network to know what its requirements are and say "no" when it needs to. What I am saying is that if you say "I don't allow the network to do that", which is how I read the comments that opened this discussion, and the application is non-adaptive or insufficiently adaptive, and edge measurement models don't work well, I'm not aware of very many additional options. dccp has been suggested, but unlike TCP/SCTP-based applications (whose behavior is defined by their transports), putting a semi-adaptive transport under a non-adaptive application doesn't make the application adaptive. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 06:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfMA-0000TO-Pi; Thu, 18 May 2006 06:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfM9-0000TJ-4w for architecture-discuss@ietf.org; Thu, 18 May 2006 06:03:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgfM7-0004WI-Sb for architecture-discuss@ietf.org; Thu, 18 May 2006 06:03:45 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 18 May 2006 03:03:44 -0700 X-IronPort-AV: i="4.05,140,1146466800"; d="scan'208"; a="322687518:sNHT30593048" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4IA3hbw013366; Thu, 18 May 2006 03:03:43 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4IA3hHc012840; Thu, 18 May 2006 03:03:43 -0700 (PDT) Received: from [193.204.93.24] (ams3-vpn-dhcp229.cisco.com [10.61.64.229]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4IA19HK010360; Thu, 18 May 2006 03:01:09 -0700 In-Reply-To: <20060517.163540.13636.1250472@webmail50.lax.untd.com> References: <20060517.163540.13636.1250472@webmail50.lax.untd.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FFEBDEE-30B0-4C50-A0F9-57048EBE6F22@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 12:03:40 +0200 To: Fergie X-Mailer: Apple Mail (2.749.3) Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=486; t=1147946623; x=1148810623; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20QoS=20Signaling=20Status=20and=20Support; X=v=3Dcisco.com=3B=20h=3Dq082b8V4cIuRdTM61eWez+Wj74U=3D; b=YB19hWgZI/0VbOFYeqT9ftAqmAbXVa+vtt/KXfGGeDC0agYGERSYubXVuAy5PduuTiiiMLnY bK8JjK4DRucIWiGi25m7CRTiES8sPWfAUcl5SivUG0llKiNYGHjscBg8; X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: eric.fleischman@boeing.com, architecture-discuss@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On May 17, 2006, at 11:34 PM, Fergie wrote: > Bell-shaped heads, that what we used to call them. ;-) Ah, yes. My children used to descend to name-calling when they couldn't win intellectually. They grew up. > I firmly believe that we have the building blocks, in diff-serv, to > actually do the things we talk about, and make end-to-end service > levels a reality. If the applications are adaptive, yes. I have a problem when they are not,or not sufficiently so. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 08:01:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghAa-00074a-9T; Thu, 18 May 2006 07:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghAY-0006ws-SI for architecture-discuss@ietf.org; Thu, 18 May 2006 07:59:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FghAX-0005fI-Is for architecture-discuss@ietf.org; Thu, 18 May 2006 07:59:54 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 18 May 2006 04:59:53 -0700 X-IronPort-AV: i="4.05,141,1146466800"; d="scan'208"; a="278847165:sNHT30549480" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k4IBxrJF022914 for ; Thu, 18 May 2006 04:59:53 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4IBxqJj003674 for ; Thu, 18 May 2006 04:59:52 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 07:59:52 -0400 Received: from cisco.com ([10.86.240.170]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 07:59:52 -0400 Date: Thu, 18 May 2006 07:59:09 -0400 From: Scott W Brim To: architecture-discuss@ietf.org Subject: Re: [arch-d] QoS Signaling Status and Support Message-ID: <20060518115909.GC5224@sbrim-wxp01> Mail-Followup-To: Scott W Brim , architecture-discuss@ietf.org References: <474EEBD229DF754FB83D256004D02108025848A8@XCH-NW-6V1.nw.nos.boeing.com> <615BD9B54CB01B41838C323DB9E91AAB98C447@esebe100.NOE.Nokia.com> <474EEBD229DF754FB83D256004D02108025848B1@XCH-NW-6V1.nw.nos.boeing.com> <20060517.163540.13636.1250472@webmail50.lax.untd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB98C447@esebe100.NOE.Nokia.com> <20060517.163540.13636.1250472@webmail50.lax.untd.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 18 May 2006 11:59:52.0240 (UTC) FILETIME=[9215CB00:01C67A72] DKIM-Signature: a=rsa-sha1; q=dns; l=1093; t=1147953593; x=1148817593; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sbrim@cisco.com; z=From:Scott=20W=20Brim=20 |Subject:Re=3A=20[arch-d]=20QoS=20Signaling=20Status=20and=20Support; X=v=3Dcisco.com=3B=20h=3D0/0Cpa6tQn5YG9VS4LvfXeJJa7I=3D; b=HdkRVSwFTTZH0MThUh8OFeGhs38UCL6QpcDo6X51evMDpOnuGp0HHsOCRlbiNG6j7vlAHMIl WxpllA8RykcNHSS+qKhPlsruqv+D7m1Ze6bIT8OXWnGMLJqnXQeOhiKC; Authentication-Results: sj-dkim-8.cisco.com; header.From=sbrim@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Just catching up ... On Thu, May 18, 2006 10:47:26AM +0300, john.loughney@nokia.com allegedly wrote: > RSVP (especially in the -TE sense) is a very successful > protocol; but there are a number of issues with RSVP > and RSVP's extensibility that impact it's further use. I think > Tony mentioned the issue about scalabililty for inter-domain > use. For clarity ... Are you separating the int-serv model with per-flow state (which doesn't scale inter-domain) from RSVP as a protocol for signaling intention and for "admission control" (which seems to work pretty well)? > I don't see a lot of what NSIS is doing as being outside of > standard IP architecture. Sure, some people might complain > about different some of the different QoS models, but I view > running different QoS models (ITU-T QoS models for example) over > NSIS protocols as not being incompatible with historic IP > architecture models, like you said earlier, tunneling non-IP > traffic over IP is well accepted practice. What are the "ITU-T QoS models" versus IETF ones? Thanks. swb _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 08:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghxY-0007n2-VY; Thu, 18 May 2006 08:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghxX-0007mj-Iq for architecture-discuss@ietf.org; Thu, 18 May 2006 08:50:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FghxX-0007v0-HN for architecture-discuss@ietf.org; Thu, 18 May 2006 08:50:31 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FghlH-0002Pp-G5 for architecture-discuss@ietf.org; Thu, 18 May 2006 08:37:55 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4ICbkP3026027; Thu, 18 May 2006 15:37:48 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 15:37:47 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 15:37:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 15:37:46 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C451@esebe100.NOE.Nokia.com> In-Reply-To: <20060518115909.GC5224@sbrim-wxp01> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6ct+ogOZvSDU0SAuSUaTN8ylKhQABBh5g From: To: , X-OriginalArrivalTime: 18 May 2006 12:37:47.0223 (UTC) FILETIME=[DE14A670:01C67A77] X-Spam-Score: -2.5 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Scott, >On Thu, May 18, 2006 10:47:26AM +0300, john.loughney@nokia.com=20 >allegedly wrote: >> RSVP (especially in the -TE sense) is a very successful=20 >protocol; but=20 >> there are a number of issues with RSVP and RSVP's extensibility that=20 >> impact it's further use. I think Tony mentioned the issue about=20 >> scalabililty for inter-domain use. > >For clarity ... Are you separating the int-serv model with=20 >per-flow state (which doesn't scale inter-domain) from RSVP as=20 >a protocol for signaling intention and for "admission control"=20 >(which seems to work pretty well)? That would be part of it, yes. >> I don't see a lot of what NSIS is doing as being outside of standard=20 >> IP architecture. Sure, some people might complain about different=20 >> some of the different QoS models, but I view running different QoS=20 >> models (ITU-T QoS models for example) over NSIS protocols as=20 >not being=20 >> incompatible with historic IP architecture models, like you said=20 >> earlier, tunneling non-IP traffic over IP is well accepted practice. > >What are the "ITU-T QoS models" versus IETF ones? ITU-T's Y.1541 vs. IntServ / DiffServ. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 12:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglGh-00038a-59; Thu, 18 May 2006 12:22:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglGg-00038T-0D for architecture-discuss@ietf.org; Thu, 18 May 2006 12:22:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglGf-0003zM-Ux for architecture-discuss@ietf.org; Thu, 18 May 2006 12:22:29 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgl5P-0004mK-Js for architecture-discuss@ietf.org; Thu, 18 May 2006 12:10:52 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA04793; Thu, 18 May 2006 09:10:44 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4IGAiG08347; Thu, 18 May 2006 11:10:44 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 09:10:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 09:10:42 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108025848B2@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <63C2797E-7658-4DC1-8083-13843BC8C45F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6Yk+/9M0HjufGQTmDnkNgCYx4YwALM0Kw From: "Fleischman, Eric" To: "Fred Baker" , X-OriginalArrivalTime: 18 May 2006 16:10:43.0686 (UTC) FILETIME=[9D723060:01C67A95] X-Spam-Score: -2.6 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org If network traffic is consistent at any given network node, so that a network node could extrapolate future events based on past or present behaviors, then I can readily resonate with what you are saying (i.e., that the node could say "yes" or "no" to received QoS signals in an intelligent fashion). However, if what the node is seeing is self-similar traffic, such that there are no discernable patterns in the past or present, then I wonder how that node could determine how it should behave in the future.=20 On the other hand, one could push back that nodes currently have very limited intelligence to make such judgements. Therefore, this really is a policy issue. The effectiveness of the policy system (when measured in terms of unused capacity) is a function of how self-similar the traffic patterns are.=20 Does this correlate with your own insights? If not, how do you see it? I believe that another relevant dimension is admission control. If one has the POTS mentality in which E2E admission control occurs at the physical or data link layers then one has an entirely different algorithm having very different properties than historic IP. Nevertheless, I see many attractive features within the POTS mentality for establishing deterministic trunking. In my own mind, the ideal system would have stochastic access in the network periphery and deterministic trunking in the backbone core. Regardless, my question for this list is whether or not signalling (whether it is NSLS or RSVP or something else) can *systematically* provide deterministic trunking in *IP environments*? What are the pros and cons that people have discovered thus far? -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 >Integrated Services, aka NSIS or RSVP equivalently and presumably =20 >other protocols if one wants to build them, allows a bottleneck =20 >interface in the network to know what its requirements are and say =20 >"no" when it needs to. What I am saying is that if you say "I don't =20 >allow the network to do that", which is how I read the comments that =20 >opened this discussion, and the application is non-adaptive or =20 >insufficiently adaptive, and edge measurement models don't work well, =20 >I'm not aware of very many additional options.=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 12:28:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglMS-0004t4-5l; Thu, 18 May 2006 12:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglMP-0004sz-Ja for architecture-discuss@ietf.org; Thu, 18 May 2006 12:28:26 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglMN-0004D3-87 for architecture-discuss@ietf.org; Thu, 18 May 2006 12:28:25 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA27929; Thu, 18 May 2006 09:27:46 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4IGRjG02213; Thu, 18 May 2006 11:27:45 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 09:27:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 09:27:43 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108025848B3@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6FOqnCLnCT95WTE2bWJ4Ns0xz7AAgYXCg From: "Fleischman, Eric" To: "John Day" , "Tschofenig, Hannes" , X-OriginalArrivalTime: 18 May 2006 16:27:43.0817 (UTC) FILETIME=[FD7DD390:01C67A97] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, It seems that our views of history are congruent and that we have formed similar observations. I have three additional questions that I'd like to ask: Do you believe that QoS signaling is an attempt to introduce CONS concepts into CLNP networks or do you view that to be an orthogonal issue? A second question is does QoS signaling in IP environments actually achieve its goals or not? Specifically, does QoS signaling in real networks enable support for latency sensitive, real time, and highly interactive applications or do IP networks still fall short in real life when compared to CONS? Third question: We've dealt with "ships in the night" multi-protocol deployments for years. Can the same network infrastructure deploy "ships in the night" CONS and CLNS systems? --Eric -----Original Message----- From: John Day [mailto:jeanjour@comcast.net]=20 Sent: Wednesday, May 17, 2006 5:39 PM To: Fleischman, Eric; Tschofenig, Hannes; architecture-discuss@ietf.org Subject: RE: [arch-d] QoS Signaling Status and Support > > >One lesson we learned during the 80s from the OSI debacle is that=20 >mixing resource-reservation lower layers over a CONS-like network layer >with best-effort CLNS network layers just don't work. The=20 >infrastructure either needs to be CONS or CLNS -- mixing them is A Bad=20 >Thing. Just for the record, OSI never attempted such a solution and in fact=20 I don't believe it really ever considered it. All it did was attempt=20 to legislate their separation. (OSI should never invited the phone=20 companies to the party, but it is doubtful the Europeans could have=20 not invited them. The only real lesson learned from the OSI debacle=20 is that if you are doing a new architecture, don't invite the legacy=20 one to join.) Actually as already pointed out, the ARPANet was more CONS than CNLS=20 for most of its life. Also it was very likely that the connection=20 nature of BBN 1822 and the use of X.25 as its replacement that=20 forestalled the congestion collapse as long as it did. Now that said, I think the CONS advocates have done a pretty lousy=20 job of understanding how it can/should be used. They seemed to be as=20 locked in their religion as the CLNS advocates are in theirs. We have seen one engineering hack proposed after another. I have=20 seen no real attempt in the last 35 years to really understand what=20 is going on with CO and CL. All I have seen are two warring factions=20 with the strong belief that the thing they are currently working on=20 will spell the demise of the other. At this point, it should be clear that neither is going to happen.=20 That should tell us that there is something about this that we don't=20 yet get. But so far all I hear on this list is how sure we are of=20 what we know. Given how little science we have to base that on, it=20 should give us considerable pause. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 12:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglMi-0004w0-OA; Thu, 18 May 2006 12:28:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglMi-0004vs-Am for architecture-discuss@ietf.org; Thu, 18 May 2006 12:28:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjTp-0004zp-OL for architecture-discuss@ietf.org; Thu, 18 May 2006 10:27:57 -0400 Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgjG0-0003OH-0f for architecture-discuss@ietf.org; Thu, 18 May 2006 10:13:41 -0400 Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id k4IEDZA15489; Thu, 18 May 2006 09:13:35 -0500 Message-ID: <0bb601c67a85$3e2048a0$6901a8c0@ssprunk> From: "Stephen Sprunk" To: , "'Fleischman, Eric'" , References: <010901c67925$f90d3120$9a01a8c0@tropos.com> Subject: Re: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 09:13:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Thus spake "Tony Li" > RSVP worked for TE purposes soley because TE is intra-domain. It would > not scale to the inter-domain. That's an interesting take, and one I'm not inclined to argue with, but RSVP-TE solves an entirely different problem than plain RSVP, however similar they may look on the surface. RSVP (and IntServ in general) failed because it requires every hop to maintain per-flow state. Even ignoring the problems with variable paths, per-flow state has been shown time and time again to be fundamentally unsuitable for large-scale networks. ISPs found this out a decade ago, and even large enterprises have been seeing it for 5+ years. RSVP-TE works on pairs of routers, which aggregate arbitrary numbers of flows. Since there's a finite number of pairs, one can design the topology to stay within the constraints of the amount of state routers can handle. Another thing is that RSVP-TE doesn't require the forwarding plane to actually pay attention to the bandwidth "reserved" to an LSP for thinks to work. If one updates each LSP to reserve current usage plus X% every Y seconds, the forwarding plane will never drop packets except in extreme circumstances (which can be dealt with by increasing X or reducing Y). The short answer, though, also explains why DiffServ is also generally seen as a failure: it's almost always cheaper to throw bandwidth at the QoS problem than to provide a real solution. It's only really tiny pipes (e.g. the last mile) where any form of QoS sees even a modicum of success. This last is why the "network neutrality" debate in the US is ultimately a moot point; sooner or later the Bells will find it cheaper to give everything best effort treatment than to extract money from people for better QoS. It's been tried over and over, and every time it has failed; nothing has changed except the press coverage. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 13:56:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgmj0-0002jh-2Z; Thu, 18 May 2006 13:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgmiy-0002jb-Ds for architecture-discuss@ietf.org; Thu, 18 May 2006 13:55:48 -0400 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fgmiv-0000Pb-Ts for architecture-discuss@ietf.org; Thu, 18 May 2006 13:55:48 -0400 Received: (qmail 1829 invoked from network); 18 May 2006 17:51:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 18 May 2006 17:51:43 -0000 Received: from LIPC ([192.168.1.88]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:56:24 -0700 From: "Tony Li" To: "'Scott W Brim'" , Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 10:55:32 -0700 Message-ID: <004901c67aa4$41f4df30$747d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060518115909.GC5224@sbrim-wxp01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ6dNJRWT74N5WSRqWFDtBALruweQALeNNg X-OriginalArrivalTime: 18 May 2006 17:56:24.0272 (UTC) FILETIME=[60BAD500:01C67AA4] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Scott, > > RSVP (especially in the -TE sense) is a very successful > > protocol; but there are a number of issues with RSVP > > and RSVP's extensibility that impact it's further use. I think > > Tony mentioned the issue about scalabililty for inter-domain > > use. > > For clarity ... Are you separating the int-serv model with per-flow > state (which doesn't scale inter-domain) from RSVP as a protocol for > signaling intention and for "admission control" (which seems to work > pretty well)? For clarity... I'm not sure that the two are separable. Our experience with RSVP is that even when used for signalling LSPs, the ISPs immediately wanted to instantiate an N^2 mesh of LSPs, quickly leading to enormous scalability issues, even intra-domain. This was also with some of the most knowledgeable ISPs who understood all of the scalability issues and yet were still unwilling to only instantiate flows as exceptions to normal forwarding. We dealt with the scalability issues by scrambling and doing the refresh reduction changes to the protocol, but even with these, the fact of the matter is that the overhead of per-flow signalling is non-trivial and that even intra-domain flows quickly end up being challenging. Put another way, since per-flow state doesn't scale, what's the value in a protocol that signals per-flow state? Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 15:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgo1h-0003HB-Jg; Thu, 18 May 2006 15:19:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgo1g-0003H6-5n for architecture-discuss@ietf.org; Thu, 18 May 2006 15:19:12 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgo1e-0006BS-W6 for architecture-discuss@ietf.org; Thu, 18 May 2006 15:19:12 -0400 Received: from [10.0.1.32] (vpn2-dhcp-90.bu.edu[168.122.80.90]) by comcast.net (sccrmhc14) with ESMTP id <20060518191909014004qvele>; Thu, 18 May 2006 19:19:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB98C444@esebe100.NOE.Nokia.com> References: <615BD9B54CB01B41838C323DB9E91AAB98C444@esebe100.NOE.Nokia.com> Date: Thu, 18 May 2006 13:27:51 -0400 To: , , From: John Day Subject: RE: [arch-d] QoS Signaling Status and Support Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: architecture-discuss@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:15 +0300 2006/05/18, wrote: >Ferg, > >>Bell-shaped heads, that what we used to call them. ;-) >> >>No offense intended. :-) > >Not really sure that the above helps. If you look at the current >state of the Internet, with consolidation of ISPs, backbone carriers, >telcos and mobile nets - the clear division between bell heads >and net heads is gone. Heck, SCTP has been discussed on this list >as a potential new way of doing things, but SCTP was originally >designed to carry SS7 over IP. I was going to challenge this claim, but the more I think about it the more I think you are right. The phone company model *is* well on its way to taking over the IETF. We have certainly drifted a long way from the fundamentals the 'Net was founded on. But then we did not really keep them current, more enshrined them. ahhh, lost opportunities. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu May 18 16:16:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgouV-0004ub-Fj; Thu, 18 May 2006 16:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgouU-0004uW-2y for architecture-discuss@ietf.org; Thu, 18 May 2006 16:15:50 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgouT-0002f0-P9 for architecture-discuss@ietf.org; Thu, 18 May 2006 16:15:50 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA22058; Thu, 18 May 2006 13:15:44 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4IKFhG19051; Thu, 18 May 2006 15:15:43 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 13:15:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Thu, 18 May 2006 13:15:40 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108025848B6@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB98C443@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6Rch7VllWvS23TjySkR2RsWrtfQAAozkAABs9kUA= From: "Fleischman, Eric" To: , , , X-OriginalArrivalTime: 18 May 2006 20:15:41.0421 (UTC) FILETIME=[D5FA91D0:01C67AB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 >I will definitely agree that many of the people bringing requirements to NSIS=20 >are coming from a telco deployment mindset. AFAIK, the goal isn't strict=20 >interworking with POTS, but how they can move their networks to be fully IP=20 >based. However, for many of service providers, their value proposition to=20 >their customers is a very high-level commitment to quality - in terms of=20 >predicability (roughly same level of service provided); >good session setup time; high service availability. Additionally, many of=20 >these deployments have SLA agreements with other companies and they are >looking for solutions on how to tie these things together. Thank you for your insightful postings. However, I am concerned about the excerpt above. The way I read it, these (telephony) entities are trying to modify IP to preserve QoS attributes in the SLAs that IP isn't designed to support. One cannot do this without changing other properties of IP, which has implications to the Internet. If the target they are trying to achieve is to provide telephony QoS service attributes over an IP network interface to their customers then there are more obvious ways to do this without changing the Internet in possibly undesirable ways. What would make more sense to me is for them to provide a VPN service to their customers having IP interfaces with legacy QoS. Specifically, establish the required QoS at the sub-IP layer using whatever protocol system they have already deployed that support those QoS attributes and then run IP on top of it. This way they would only use the IP layer as an interoperable transport without having to struggle with issues associated with making fundamental changes to IP itself. The approach I'm suggesting can be locally done with minimal changes to current infrastructures. It also doesn't require the establishment of possibly dubeous signaling translations between protocols having very different state machines and semantics nor does it necessitate a radical re-design of IP. Wouldn't this be far easier for everyone? Is there really a need for NSIS? If so, what is it? >Some early tests, using well-known RSVP implementations have shown that a few NSIS >implementations scale a bit better that RSVP, at around 60k sessions, if I=20 >remember right. I think there is some published=20 >results about this, that I could post a link to if anyone is interested. I am definitely interested in seeing these performance and scaling results. Thanks! _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri May 19 02:13:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyCq-0003kM-ED; Fri, 19 May 2006 02:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyCp-0003jh-Gb for architecture-discuss@ietf.org; Fri, 19 May 2006 02:11:23 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgy5l-0004kW-PL for architecture-discuss@ietf.org; Fri, 19 May 2006 02:04:08 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4J63uH0031611; Fri, 19 May 2006 09:03:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 09:03:49 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 09:03:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] QoS Signaling Status and Support Date: Fri, 19 May 2006 09:03:48 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C453@esebe100.NOE.Nokia.com> In-Reply-To: <474EEBD229DF754FB83D256004D02108025848B3@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] QoS Signaling Status and Support Thread-Index: AcZ6FOqnCLnCT95WTE2bWJ4Ns0xz7AAgYXCgABxfZqA= From: To: , , , X-OriginalArrivalTime: 19 May 2006 06:03:48.0965 (UTC) FILETIME=[FEFE7950:01C67B09] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Eric, >Do you believe that QoS signaling is an attempt to introduce=20 >CONS concepts into CLNP networks or do you view that to be an=20 >orthogonal issue? Orthogonal - IP is connection-less (for the most part) but above IP is TCP, which is connection-oriented, at least on an end-to-end basis, but it doesn't require static state along the path. Toss in another dozen or so protocols, some that are more-or-less hop-by-hop, and things are more murky. However, I think the networking layer should be connection-less. >A second question is does QoS signaling in IP environments=20 >actually achieve its goals or not? Specifically, does QoS=20 >signaling in real networks enable support for latency=20 >sensitive, real time, and highly interactive applications or=20 >do IP networks still fall short in real life when compared to CONS? QoS signaling still is not mature, IMO, so I cannot categorically answer this, but let's say that I have seen enough results that make me think that you can good results, even under heavy traffic. As you could probably tell by my email address, I deal with a lot of a lot of wireless topics, and it seems that with soon-to-be deployed wireless l2s, we're seeing a lot better performance with VoIP than with traditional circuit-switched voice - better on an end-to-end basis and also better spectral usage and network usage. >Third question: We've dealt with "ships in the night"=20 >multi-protocol deployments for years. Can the same network=20 >infrastructure deploy "ships in the night" CONS and CLNS systems? Hard to say, actually. I favor a more 'free-market' approach towards networking - people are going to deploy what they think they need - and if their deployment doesn't meet market / consumer needs, then it goes away. It currently seems like there is a lot of incentive to move to CLNS systems, but the leap-of-faith needed believe that they can achieve their needs with CLNS. To put an arch-d spin on this, we are really seeing the development of a hybrid network, where tradition PSTN and Cellular systems are migrating to IP networks. However, the more difficult part is where people are grafting their PSTN business models to IP, and trying to ensure that they have control points in the IP network, to ensure their business models. I've lately been talking to a number of large mobile network providers, and when you talk to the people running their networks, they are actually very IP friendly and know what it takes to meet user needs - but it is usually back in the corporate office that IP knowledge is lacking. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri May 19 04:09:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh029-00035E-Vg; Fri, 19 May 2006 04:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh028-000359-OI for architecture-discuss@ietf.org; Fri, 19 May 2006 04:08:28 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh026-00048z-Ao for architecture-discuss@ietf.org; Fri, 19 May 2006 04:08:28 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Fh023-0000zm-7S; Fri, 19 May 2006 10:08:25 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id E6295869C; Fri, 19 May 2006 10:08:22 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Fh022-0006Yq-CC; Fri, 19 May 2006 10:08:22 +0200 Message-ID: <446D7CF5.3030101@tm.uka.de> Date: Fri, 19 May 2006 10:08:21 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: tony.li@tony.li Subject: Re: [arch-d] QoS Signaling Status and Support References: <004901c67aa4$41f4df30$747d14ac@tropos.com> In-Reply-To: <004901c67aa4$41f4df30$747d14ac@tropos.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Tony > For clarity... I'm not sure that the two are separable. Our experience > with RSVP is that even when used for signalling LSPs, the ISPs > immediately wanted to instantiate an N^2 mesh of LSPs, quickly leading > to enormous scalability issues, even intra-domain. This was also with > some of the most knowledgeable ISPs who understood all of the > scalability issues and yet were still unwilling to only instantiate > flows as exceptions to normal forwarding. > > We dealt with the scalability issues by scrambling and doing the refresh > reduction changes to the protocol, but even with these, the fact of the > matter is that the overhead of per-flow signalling is non-trivial and > that even intra-domain flows quickly end up being challenging. > > Put another way, since per-flow state doesn't scale, what's the value in > a protocol that signals per-flow state? I would not generally say per-flow state doesn't scale. It actually depends on _where_ you keep/manage state. If it is not in the core and only at the boundary/first-hop then I don't expect scalability problems. The tool for this is aggregation. When considering QoS for data forwarding that's the main difference between the DiffServ and IntServ approaches. However, you also need this type of aggregation in the "control plane", e.g. for signaling/admission control, otherwise you run into scalability problems there, too. Regards, Roland _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri May 19 11:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7H8-0007yY-Ls; Fri, 19 May 2006 11:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7H6-0007yT-SM for architecture-discuss@ietf.org; Fri, 19 May 2006 11:52:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7H5-0000N3-Hm for architecture-discuss@ietf.org; Fri, 19 May 2006 11:52:24 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 May 2006 17:52:23 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4JFqMUE014306; Fri, 19 May 2006 17:52:22 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 May 2006 17:52:21 +0200 Received: from [10.61.65.45] ([10.61.65.45]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 May 2006 17:52:20 +0200 Message-ID: <446DE9B2.9070808@cisco.com> Date: Fri, 19 May 2006 11:52:18 -0400 From: Scott W Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Thunderbird/1.5.0.2 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: tony.li@tony.li Subject: Re: [arch-d] QoS Signaling Status and Support References: <004901c67aa4$41f4df30$747d14ac@tropos.com> In-Reply-To: <004901c67aa4$41f4df30$747d14ac@tropos.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 15:52:21.0107 (UTC) FILETIME=[36ABBC30:01C67B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 05/18/2006 13:55 PM, Tony Li allegedly wrote: >>> RSVP (especially in the -TE sense) is a very successful >>> protocol; but there are a number of issues with RSVP >>> and RSVP's extensibility that impact it's further use. I think >>> Tony mentioned the issue about scalabililty for inter-domain >>> use. >> For clarity ... Are you separating the int-serv model with per-flow >> state (which doesn't scale inter-domain) from RSVP as a protocol for >> signaling intention and for "admission control" (which seems to work >> pretty well)? > > For clarity... I'm not sure that the two are separable. Our experience > with RSVP is that even when used for signalling LSPs, the ISPs > immediately wanted to instantiate an N^2 mesh of LSPs, quickly leading > to enormous scalability issues, even intra-domain. This was also with > some of the most knowledgeable ISPs who understood all of the > scalability issues and yet were still unwilling to only instantiate > flows as exceptions to normal forwarding. So if they don't separate them in practice, then our claim that a "dual mode" architecture has the lowest overall complexity doesn't hold up in reality, and we really do need QoS routing? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri May 19 12:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh82w-0006MV-Tv; Fri, 19 May 2006 12:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh82v-0006CB-9r for architecture-discuss@ietf.org; Fri, 19 May 2006 12:41:49 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh82s-0003PK-TE for architecture-discuss@ietf.org; Fri, 19 May 2006 12:41:49 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k4JGfjwq016058; Fri, 19 May 2006 09:41:45 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k4JGfjh1016057; Fri, 19 May 2006 09:41:45 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 19 May 2006 09:41:45 -0700 From: David Meyer To: Scott W Brim Subject: Re: [arch-d] QoS Signaling Status and Support Message-ID: <20060519164145.GA16041@1-4-5.net> References: <004901c67aa4$41f4df30$747d14ac@tropos.com> <446DE9B2.9070808@cisco.com> Mime-Version: 1.0 In-Reply-To: <446DE9B2.9070808@cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1744491080==" Errors-To: architecture-discuss-bounces@ietf.org --===============1744491080== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 19, 2006 at 11:52:18AM -0400, Scott W Brim wrote: > On 05/18/2006 13:55 PM, Tony Li allegedly wrote: > >>> RSVP (especially in the -TE sense) is a very successful > >>> protocol; but there are a number of issues with RSVP=20 > >>> and RSVP's extensibility that impact it's further use. I think > >>> Tony mentioned the issue about scalabililty for inter-domain > >>> use. =20 > >> For clarity ... Are you separating the int-serv model with per-flow > >> state (which doesn't scale inter-domain) from RSVP as a protocol for > >> signaling intention and for "admission control" (which seems to work > >> pretty well)? > >=20 > > For clarity... I'm not sure that the two are separable. Our experience > > with RSVP is that even when used for signalling LSPs, the ISPs > > immediately wanted to instantiate an N^2 mesh of LSPs, quickly leading > > to enormous scalability issues, even intra-domain. This was also with > > some of the most knowledgeable ISPs who understood all of the > > scalability issues and yet were still unwilling to only instantiate > > flows as exceptions to normal forwarding. >=20 > So if they don't separate them in practice, then our claim that a "dual > mode" architecture has the lowest overall complexity doesn't hold up in > reality, and we really do need QoS routing? What was the "claim" around "dual mode" architecture (and what is a dual mode architecture)? Thnx, --dmm --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEbfVJORgD1qCZ2KcRAjC3AJ0fANqb5XXg+ywjLZ352vTV2kVGPwCfVVZ4 72YRyZnWph3i4uVQhkyvy1I= =6SJ/ -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- --===============1744491080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1744491080==-- From architecture-discuss-bounces@ietf.org Fri May 19 12:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8JI-0001Vi-79; Fri, 19 May 2006 12:58:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8JH-0001Vd-EJ for architecture-discuss@ietf.org; Fri, 19 May 2006 12:58:43 -0400 Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8JG-0004w8-1j for architecture-discuss@ietf.org; Fri, 19 May 2006 12:58:43 -0400 Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id k4JGwIA07381; Fri, 19 May 2006 11:58:18 -0500 Message-ID: <0e9601c67b65$6a901a60$6901a8c0@ssprunk> From: "Stephen Sprunk" To: "Roland Bless" , References: <004901c67aa4$41f4df30$747d14ac@tropos.com> <446D7CF5.3030101@tm.uka.de> Subject: Re: [arch-d] QoS Signaling Status and Support Date: Fri, 19 May 2006 11:58:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Thus spake "Roland Bless" > Hi Tony >> Put another way, since per-flow state doesn't scale, what's the value in >> a protocol that signals per-flow state? > > I would not generally say per-flow state doesn't scale. > It actually depends on _where_ you keep/manage state. > If it is not in the core and only at the boundary/first-hop > then I don't expect scalability problems. Per-flow state doesn't even work at the first-hop router these days. Larger end-user networks see problems with per-flow state in normal traffic scenarios, and even small sites can see per-flow state melt their networks when they get hit with the virus/worm/DDoS du jour. If we have a "solution" that doesn't even scale if only used at the edge, what hope is there of it working in the core? S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss