From nsis-bounces@ietf.org Wed Nov 02 08:54:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJ3z-0006nu-A3; Wed, 02 Nov 2005 08:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJ3x-0006nk-VF for nsis@megatron.ietf.org; Wed, 02 Nov 2005 08:54:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07128 for ; Wed, 2 Nov 2005 08:53:39 -0500 (EST) Message-Id: <200511021353.IAA07128@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXJIY-0002GR-An for nsis@ietf.org; Wed, 02 Nov 2005 09:09:07 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXJ3v-0001rN-CS; Wed, 02 Nov 2005 13:53:59 +0000 To: nsis@ietf.org Date: Wed, 02 Nov 2005 05:53:59 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: jon.peterson@neustar.biz, mankin@psg.com Subject: [NSIS] diffserv control plane discussion - please participate X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, NSIS folks, The OPS area has hosted a half hour discussion on diffserv control plane in their opsarea meeting. They did consult the TSV ADs, and we have talked about how this is strongly a topic in our area, with work already going on in NSIS and with related activity in TSVWG. Though it says "proposed working group", this is far from a done deal or a deal in that area. The meeting has been intentionally scheduled not to have TSV conflicts. We expect to put in a talk about the ongoing diffserv control plane work (more on that not from me). Please participate in the meeting and shape the ongoing and future IETF work on this topic. Allison Draft Agenda (v1) for the Operations & Management Open Area Meeting IETF64 When: 1740-1950, MONDAY, November 7, 2005 Where: Salon 2/3 A. Administrative stuff [snip] (David Kessens, Bert Wijnen) B. Proposed working groups - AAA Maintenance (John Loughney, speaker not yet confirmed) - Diffserv Control Plane Elements (DCPEL) (Kathleen Nichols, Scott Bradner) mailing list: dcpel@ietf.org archive: https://www1.ietf.org/mailman/listinfo/dcpel [snip] Also in that slot: Salon 1 APP calsify Calendaring and Scheduling Standards Simplification WG Salon C INT mipshop MIPv6 Signaling and Handoff Optimization WG Oak INT ntp Network Time Protocol WG Salon 2/3 OPS opsarea Operations and Management Open Area Salon F RTG rpsec Routing Protocols Security Requirements WG - CANCELLED Cypress SEC smime S/MIME Mail Security WG - RPSEC is cancelled, I'm told _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 02 12:23:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMDK-00026Q-Eh; Wed, 02 Nov 2005 12:15:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMDH-000264-VW for nsis@megatron.ietf.org; Wed, 02 Nov 2005 12:15:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22386 for ; Wed, 2 Nov 2005 12:15:30 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMRt-0004Up-LY for nsis@ietf.org; Wed, 02 Nov 2005 12:30:59 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id jA2HFaV9032301; Wed, 2 Nov 2005 18:15:36 +0100 Received: from mhpahx2c.ww002.siemens.net (mhpahx2c.mch.sbs.de [139.25.165.55]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id jA2HFaec009450; Wed, 2 Nov 2005 18:15:36 +0100 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx2c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Nov 2005 18:15:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Date: Wed, 2 Nov 2005 18:15:35 +0100 Message-ID: <391E6FBF5E786940B9E2F7CA6376C708DE44EF@blns00fa.ww002.siemens.net> Thread-Topic: [NSIS] RE: PACKET_CLASSIFIER in QSPEC Thread-Index: AcXYmxHrYs1JWeuPQ/6g3prlEgAfAgHMqATA From: "Kappler, Cornelia" To: "Roland Bless" , "Ash, Gerald R \(Jerry\), ALABS" , "Georgios Karagiannis" X-OriginalArrivalTime: 02 Nov 2005 17:15:36.0431 (UTC) FILETIME=[0A532FF0:01C5DFD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all,=20 I would like to argue two points: (1) "stacked classfiers" as well as "each QoS model can select to use other MRI parameters" may lead to a single QoS NSLP session reserving resources for two or more separate flows. This has been pointed out by several people. Obviously, this is a bad thing. So in consequence, we should agree there is only one valid packet classifier for a given session.=20 (2) the packet classifier depends rather little on the QoS Model. =20 I am aware Georgios, Roland,...said the opposite. However, I think there is exactly one parameter in the packet classifier that to some extent is QoS Model dependent, namely DSCP! Any DiffServ-based QoS Model is likely to use the DSCP as a packet classifier. And if this DiffServ QoS Model is used somewhere in the middle of a data path, whereas the QNI didnt foresee usage of DSCP, we do have an issue.=20 Vice versa however, I can imagine any other QoS Model to include the DSCP in its packet classifier. And, checking all other parameters (IP source / dest, etc) they are not at all QoS Model specific.=20 So I think we need to rephrase the question: Should we accomodate a scenario where a (edge) QNE is allowed to change the flow identifier because it appears more suitable to its QoS Model? In my mind, we shouldnt, because of (1). What the QNE should do in this case is tunnel the ongoing NSIS session and set up a new one with a packet classifier to its liking. (This argument implies there is no reason to place the packet classifier in the QSPEC) Best regards, Cornelia > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: Montag, 24. Oktober 2005 15:01 > To: Ash, Gerald R (Jerry), ALABS > Cc: Georgios Karagiannis; john.loughney@nokia.com; Kappler,=20 > Cornelia; nsis@ietf.org > Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >=20 >=20 > Hi Jerry, >=20 > Ash, Gerald R (Jerry), ALABS write: > > It appears that the packet_classifier could be done either=20 > in QoS-NSLP > > or QSPEC. However, Cornelia had concerns about putting it=20 > in QSPEC so I > > think we should hear from her again on this (I believe she=20 > is away at > > the moment). Robert also expressed some concerns I believe. > >=20 > > It still seems to me that the packet_classifier identifies 'what' > > reservation is being made, and does not identify 'how much stuff' is > > reserved. By that distinction, it belongs in QoS-NSLP=20 > (this is John's > > and Robert's logic also). I also don't understand why putting the > > packet_classifier in QoS-NSLP is any more complex or prone to errors > > than putting it in QSPEC. >=20 > And Georgious point was that the packet classifier depends > probably on the QoS model or is at least somehow related to > it. So if put into QoS NSLP you possibly end up with a stack > of packet classifiers in addition to the QSPEC stack. > Integrating packet classifiers into QSPECs would remove the need > to support also a separate stack of packet classifiers. > If thinking about it from a DiffServ perspective I would support > the view that a packet classifier is probably QoS model dependent. > However, in DiffServ you also need additional elements like markers > or droppers for a useful traffic conditioning mechanism. >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 03 00:56:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXY5n-0004wd-W7; Thu, 03 Nov 2005 00:56:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXY5m-0004vm-0I for nsis@megatron.ietf.org; Thu, 03 Nov 2005 00:56:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08238 for ; Thu, 3 Nov 2005 00:56:32 -0500 (EST) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXYKU-0006wq-Oe for nsis@ietf.org; Thu, 03 Nov 2005 01:12:08 -0500 Received: from [84.132.179.120] (p5484B378.dip0.t-ipconnect.de [::ffff:84.132.179.120]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Thu, 03 Nov 2005 06:56:44 +0100 id 000083A8.4369A69C.00002701 Message-ID: <4369A69D.3090309@cs.uni-goettingen.de> Date: Thu, 03 Nov 2005 06:56:45 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [NSIS] design options for diagnostics functions X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, We have incorporated discussions with some NSIS folks and put down some thoughts on design options for diagnostics functions in a document. Before the ietf queue is reopened, you may find it in the following URL: http://user.informatik.uni-goettingen.de/~fu/nsis/diagnostics/draft-fu-nsis-diagnostics-nslp-00.txt (sorry for being late) Abstract: The Next Steps in Signaling protocol suite aims to provide a way to communicate with network intermediaries. As such, it is desirable to offer generic diagnostics function for NSIS users and system administrators to make the functionality provided by the network more transparent (e.g., to identify particular NSLPs, to determine to which degree the network supports NSIS, GIST state or specific NSLP session information along a given path). Instead of suggesting one specific solution we highlight the different design options of some simple, stateless diagnostics functions from a querying node to a responding node. These preliminary thoughts should help the working group to have a more structure discussion in this problem space. Your suggestions and comments are very appreciated. Best regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 03 03:14:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXaFC-0006Kz-FS; Thu, 03 Nov 2005 03:14:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXaFB-0006JV-2D for nsis@megatron.ietf.org; Thu, 03 Nov 2005 03:14:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13885 for ; Thu, 3 Nov 2005 03:14:22 -0500 (EST) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXaTv-0004Bg-M3 for nsis@ietf.org; Thu, 03 Nov 2005 03:30:00 -0500 Received: from [84.132.179.120] (p5484B378.dip0.t-ipconnect.de [::ffff:84.132.179.120]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Thu, 03 Nov 2005 09:14:42 +0100 id 000083F2.4369C6F2.0000730E Message-ID: <4369C6E6.7070908@cs.uni-goettingen.de> Date: Thu, 03 Nov 2005 09:14:30 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kappler, Cornelia" Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: <391E6FBF5E786940B9E2F7CA6376C708DE44EF@blns00fa.ww002.siemens.net> In-Reply-To: <391E6FBF5E786940B9E2F7CA6376C708DE44EF@blns00fa.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , Roland Bless , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cornelia, I just read thru this thread and support your observations. Xiaoming Kappler, Cornelia wrote: > Dear all, > > I would like to argue two points: > > (1) "stacked classfiers" as well as "each QoS model can select to use > other MRI parameters" may lead to a single QoS NSLP session reserving > resources for two or more separate flows. > > This has been pointed out by several people. Obviously, this is a bad > thing. So in consequence, we should agree there is only one valid packet > classifier for a given session. > > (2) the packet classifier depends rather little on the QoS Model. > > I am aware Georgios, Roland,...said the opposite. However, I think there > is exactly one parameter in the packet classifier that to some extent is > QoS Model dependent, namely DSCP! Any DiffServ-based QoS Model is likely > to use the DSCP as a packet classifier. And if this DiffServ QoS Model > is used somewhere in the middle of a data path, whereas the QNI didnt > foresee usage of DSCP, we do have an issue. > > Vice versa however, I can imagine any other QoS Model to include the > DSCP in its packet classifier. And, checking all other parameters (IP > source / dest, etc) they are not at all QoS Model specific. > > So I think we need to rephrase the question: Should we accomodate a > scenario where a (edge) QNE is allowed to change the flow identifier > because it appears more suitable to its QoS Model? In my mind, we > shouldnt, because of (1). What the QNE should do in this case is tunnel > the ongoing NSIS session and set up a new one with a packet classifier > to its liking. > > (This argument implies there is no reason to place the packet classifier > in the QSPEC) > > Best regards, Cornelia > > > >>-----Original Message----- >>From: Roland Bless [mailto:bless@tm.uka.de] >>Sent: Montag, 24. Oktober 2005 15:01 >>To: Ash, Gerald R (Jerry), ALABS >>Cc: Georgios Karagiannis; john.loughney@nokia.com; Kappler, >>Cornelia; nsis@ietf.org >>Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC >> >> >>Hi Jerry, >> >>Ash, Gerald R (Jerry), ALABS write: >> >>>It appears that the packet_classifier could be done either >> >>in QoS-NSLP >> >>>or QSPEC. However, Cornelia had concerns about putting it >> >>in QSPEC so I >> >>>think we should hear from her again on this (I believe she >> >>is away at >> >>>the moment). Robert also expressed some concerns I believe. >>> >>>It still seems to me that the packet_classifier identifies 'what' >>>reservation is being made, and does not identify 'how much stuff' is >>>reserved. By that distinction, it belongs in QoS-NSLP >> >>(this is John's >> >>>and Robert's logic also). I also don't understand why putting the >>>packet_classifier in QoS-NSLP is any more complex or prone to errors >>>than putting it in QSPEC. >> >>And Georgious point was that the packet classifier depends >>probably on the QoS model or is at least somehow related to >>it. So if put into QoS NSLP you possibly end up with a stack >>of packet classifiers in addition to the QSPEC stack. >>Integrating packet classifiers into QSPECs would remove the need >>to support also a separate stack of packet classifiers. >>If thinking about it from a DiffServ perspective I would support >>the view that a packet classifier is probably QoS model dependent. >>However, in DiffServ you also need additional elements like markers >>or droppers for a useful traffic conditioning mechanism. >> >>Regards, >> Roland >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 03 03:53:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXaqh-0001XY-0Y; Thu, 03 Nov 2005 03:53:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXaqe-0001Ug-FI for nsis@megatron.ietf.org; Thu, 03 Nov 2005 03:53:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15367 for ; Thu, 3 Nov 2005 03:53:05 -0500 (EST) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXb5O-0006Tr-HR for nsis@ietf.org; Thu, 03 Nov 2005 04:08:43 -0500 Received: from [172.22.0.51] (tmg51.tmg.loc [::ffff:172.22.0.51]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Thu, 03 Nov 2005 09:53:25 +0100 id 000083E4.4369D005.000004FC Message-ID: <4369CFF9.8020209@cs.uni-goettingen.de> Date: Thu, 03 Nov 2005 09:53:13 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stiemerling , Elwyn Davies , nsis@ietf.org Subject: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP References: <43575607.5090808@dial.pipex.com> <753AD8E473371FEFB0F10109@[10.1.1.109]> In-Reply-To: <753AD8E473371FEFB0F10109@[10.1.1.109]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Martin, Elwyn, My comments inline: Martin Stiemerling wrote: > Hi Elwyn, > > | A query message for NATFW NSLP specifically would be able to return the > | sequnce of device types (NAT or FW or combined) > | plus addressing information for the node (in the case of a NAT public and > | private sides). This is a strictly limited set > | of information which does not need to worry about how rules are > | formulated. It is simple to specify and gives the > | substrate on which more complex queries could be built using other > | (targeted) protocols. > > This proposal sounds realistic, since the response is limited to a > very specific information. Past proposals included reporting of > policy rules installed at the involved firewalls/NATs. In my opinion, > reporting of the policy rules is challenging in many ways: > - Administrators do not like others to see the real policy rules will > all parameters, > - Returning policy rules per hop may result in quite large messages > - Representation of any thinkable policy rule in a generic and > interoperable seem quite difficult. (Consider all the possible > parameters of firewall/NAT implementations and the number of > vendors + software version) If the query is just to collect NAT/FW device types along the path, there is an issue whether this should be put in a general tool or inside NAT/FW NSLP. > > | > | I suspect a similar query mechanism for QoS NSLP would also be useful. > | > | There would be some possible security issues. Would a remote node wish > | to give away its address, or even its existence? > > I guess that many operators do not like others to see details about > their infrastructure. Especially, when nodes from outside the network > can learn about the infrastructure. As you have said below, a > scoping mechanism is required. Furthermore, I would suggest to > declare the NATFW Query mechanism optional, i.e., nodes may enter > the IP address but they must not. It might be the case a sysadm may desire to query such info in its domain (or even other neighboring trusted domains). > > | Nodes should (I guess) be able to 'pass' on the message - forward it > | without filling in information - and scope mechanisms might apply > | so that the message is turned round at the edge of a domain. > | > | I think it has to be at the NSLP level because of the specificity of > | sessions. > > Right. If such a capability is desired, I agree this is probably the right direction to go. Xiaoming > > Best regards, > > Martin > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 03 03:56:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXatm-00038S-Pe; Thu, 03 Nov 2005 03:56:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXatl-00037n-12 for nsis@megatron.ietf.org; Thu, 03 Nov 2005 03:56:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15531 for ; Thu, 3 Nov 2005 03:56:18 -0500 (EST) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXb8V-0006cY-Ai for nsis@ietf.org; Thu, 03 Nov 2005 04:11:56 -0500 Received: from [172.22.0.51] (tmg51.tmg.loc [::ffff:172.22.0.51]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Thu, 03 Nov 2005 09:56:38 +0100 id 000083E4.4369D0C6.000006E6 Message-ID: <4369D0BA.4010109@cs.uni-goettingen.de> Date: Thu, 03 Nov 2005 09:56:26 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner , David R Oran Subject: Re: QoS Queries (Was: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jukka, David, Jukka MJ Manner wrote: > Hi, > > This is a thread about the NATFW, and you are talking about QoS, but I'm > still answering. ;) > > You can ask that for resources on the exact data path you intend to send > your data. The answer you get depends on your QUERY message, but in > practise you should get this information in return, yes. Still you raised > an interesting point, as I've thought that any authorization is done to > see whether you are allowed in general to query for resources. Yet, you > might also ask, whether you are allowed to reserve resources in the end. > This needs some clarification in our work, Hannes? > > Currently, you can't trace the route, at least not that I know of. If I understand it correctly, currently QoS queries only work like RSVP PATH with Adspec mostly used to gather available resource information along the path. If one desires the RFC2745-like functions, some possibilities are described in http://user.informatik.uni-goettingen.de/~fu/nsis/diagnostics/draft-fu-nsis-diagnostics-nslp-00.txt Thanks, Xiaoming > > Cheers, > Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 04 04:49:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXyBx-0002hL-GY; Fri, 04 Nov 2005 04:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXyBw-0002gm-2n for nsis@megatron.ietf.org; Fri, 04 Nov 2005 04:49:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06841 for ; Fri, 4 Nov 2005 04:48:36 -0500 (EST) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXyQr-0000Bw-2V for nsis@ietf.org; Fri, 04 Nov 2005 05:04:28 -0500 Received: (qmail invoked by alias); 04 Nov 2005 09:48:40 -0000 Received: from p54A310DF.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.16.223] by mail.gmx.net (mp018) with SMTP; 04 Nov 2005 10:48:40 +0100 X-Authenticated: #4469397 From: Thomas Herzog To: nsis@ietf.org Subject: [NSIS] GIST: Switching to C-Mode after setup on behalf of the responder node Date: Fri, 4 Nov 2005 10:44:08 +0100 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511041044.09135.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, together, I find it very hard to install a Messaging Association on behalf of the responder node, when there is currently only D-Mode set up for the connection. On the QN side, the QN can do so by using a refresh cycle and asking for stack proposal and switching to C-Mode by initiating a MA with the confirm. On the RN side, GIST will get a SendMessage call from a NSLP (which needs C-Mode), find Routing State and finds out that it has only D-Mode available. What to do now, as a Refresh cycle cannot be initiated from the RN. A new Handshake initiated from the RN would also be quite problematic, as the QN is in some state of its QN-SM, thus it will not respond to queries for the already installed state (and will not transit into Responder Role). What to do in that case? It is thinkable, that such a case happens, imagine a Responding NSLP not requiring C-Mode (as it knows, the connection is set up 'unreliable'/'insecure'), but maybe it wants to transmit a large amount of data which cannot be sent in D-Mode. Wouldn't it be a good idea to include a new rule in QN-SM in State "established" to kill all state and start RN-SM if a GIST query arrives for the state? Thus a RN may "upgrade" the connection properties by initiating a new handshake, starting QN-SM and the "roles" would be swapped? Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 04 06:08:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXzQZ-0001lr-39; Fri, 04 Nov 2005 06:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXzQX-0001ll-P3 for nsis@megatron.ietf.org; Fri, 04 Nov 2005 06:08:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12626 for ; Fri, 4 Nov 2005 06:07:47 -0500 (EST) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXzfW-0002ri-NY for nsis@ietf.org; Fri, 04 Nov 2005 06:23:39 -0500 Received: from [172.22.0.51] (tmg51.tmg.loc [::ffff:172.22.0.51]) (AUTH: LOGIN fu, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 04 Nov 2005 12:08:01 +0100 id 00008480.436B4111.000072DE Message-ID: <436B410D.2050707@cs.uni-goettingen.de> Date: Fri, 04 Nov 2005 12:07:57 +0100 From: Xiaoming Fu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-07.txt References: <9473683187ADC049A855ED2DA739ABCA09FA953E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA953E@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry, While updating the Controlled-Load Services QOSM CLS we figured out another open issue: * What object(s) should a Query message contain? * More specificially (copied from http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledload-03.txt): 3. Issue concerning the "RSVP-Style Reservation". In RSVP, the PATH message sends a Sender_TSPEC (primarily token bucket reflecting the sender traffic's characteristics) in addition to ADSpec. The token bucket in the RESERVE message is an update of the token bucket in the PATH message considering the available bandwidth. In QoS NSLP, there are three alternative means for composing and interpreting the QSPEC in a QUERY message: o Use a single QoS Available object (which in turn carries available bandwidth in QUERY, allow each QNE be able to modify and forward it, and let the QNR originate a QoS Desired (Token Bucket) object based on this QoS Available object. The current draft utilizes this approach, however it is not clear whether this will be done. o Use a token bucket (QNE-readonly) plus available bandwidth (QNE readable and writable) in QUERY, and let the QNR compose the QoS Desired based on the available bandwidth information gathered along the path and the token bucket originally specified by the QNI. This is more similar to RSVP/IntServ but requires further study. o Use a single Token Bucket parameter as QoS Available object in QUERY, let QNEs interpret certain fields in the Token Bucket (e.g., average/peak rate) as bandwidth, and the QNR compose a new Token Bucket as QoS Desired. This seems to simplify the object but may need different interpretations of a Token Bucket. We would be glad to hear views on this. Cheers, Xiaoming Ash, Gerald R (Jerry), ALABS wrote: > Hi All, > > Please review and comment on the updated 'QoS-NSLP QSPEC Template' I-D > at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt. > > The updates include the following (including -06 updates): > > 1. defined "error flag" for error handling, Section 4.5.1 > 2. defined "not-supported flag" and "tunneled parameter flag", Section > 4.5.2 > 3. updated bit error rate (BER) parameter to packet loss ratio (PLR) > parameter, Section 5.2.2 & 7.2.10 > 4. added packet error ratio (PER) parameter, Section 5.2.2 & 7.2.11 > 5. added text (from David Black) on DiffServ QSPEC example, Section 6.2 > 6. coding checked by independent expert and updated to include RE flags > in QSPEC objects and MENT flags in QSPEC parameters, Section 7 > 7. expanded IANA Considerations, Section 9 > > Remaining open issues include: > > 1. placement of packet_classifier in QSPEC or QoS-NSLP? > > Please review and comment. > > Thanks, > Regards, > Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 04 07:31:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY0jf-0007bM-Sa; Fri, 04 Nov 2005 07:31:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY0je-0007b5-BV for nsis@megatron.ietf.org; Fri, 04 Nov 2005 07:31:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16239 for ; Fri, 4 Nov 2005 07:31:35 -0500 (EST) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EY0ya-0004rj-Md for nsis@ietf.org; Fri, 04 Nov 2005 07:47:28 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1131107497!9488963!3 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 32318 invoked from network); 4 Nov 2005 12:31:44 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-120.messagelabs.com with SMTP; 4 Nov 2005 12:31:44 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA001BD1FA; Fri, 4 Nov 2005 07:31:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-07.txt Date: Fri, 4 Nov 2005 06:31:43 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA960A@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-07.txt Thread-Index: AcXhMAi8bUt4fwSfTdayHwzrFoNQIAACf9rg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Xiaoming Fu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Xiaoming, Thanks for your comments, my initial suggestion is below. We can discuss further in Vancouver. Thanks, Regards, Jerry=20 > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de]=20 > Sent: Friday, November 04, 2005 6:08 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org > Subject: Re: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qspec-07.txt >=20 > Hi Jerry, >=20 > While updating the Controlled-Load Services QOSM CLS we figured out=20 > another open issue: >=20 > * What object(s) should a Query message contain? * >=20 > More specifically (copied from=20 > http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controll edload-03.txt): > 3. Issue concerning the "RSVP-Style Reservation". In=20 > RSVP, the PATH message sends a Sender_TSPEC (primarily token > bucket reflecting the sender traffic's characteristics) in > addition to ADSpec. The token bucket in the RESERVE message is > an update of the token bucket in the PATH message considering the > available bandwidth. In QoS NSLP, there are three alternative > means for composing and interpreting the QSPEC in a QUERY > message: > o Use a single QoS Available object (which in turn carries > available bandwidth in QUERY, allow each QNE be able to modify=20 > and forward it, and let the QNR originate a QoS Desired (Token=20 > Bucket) object based on this QoS Available object. The > current draft utilizes this approach, however it is not clear > whether this will be done. > o Use a token bucket (QNE-readonly) plus available bandwidth (QNE > readable and writable) in QUERY, and let the QNR compose the > QoS Desired based on the available bandwidth information > gathered along the path and the token bucket originally > specified by the QNI. This is more similar to RSVP/IntServ but > requires further study. > o Use a single Token Bucket parameter as QoS Available object in > QUERY, let QNEs interpret certain fields in the Token Bucket > (e.g., average/peak rate) as bandwidth, and the QNR compose a > new Token Bucket as QoS Desired. This seems to simplify the > object but may need different interpretations of a Token > Bucket. >=20 > We would be glad to hear views on this. For simplicity, I'd suggest the third approach. Token Bucket parameter [r] would normally translate directly to average bandwidth. If both [r] and [p] are used, then a mapping using both average/peak statistics would map to 'bandwidth'. It would be good to hear other views on this. > Cheers, > Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 04 08:47:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY1uG-0007Zt-Dx; Fri, 04 Nov 2005 08:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY1uE-0007Zl-ON for nsis@megatron.ietf.org; Fri, 04 Nov 2005 08:46:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21188 for ; Fri, 4 Nov 2005 08:46:35 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY29E-0007SF-TZ for nsis@ietf.org; Fri, 04 Nov 2005 09:02:29 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA4Dgm7C014094 for ; Fri, 4 Nov 2005 15:42:50 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 15:46:44 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 15:46:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2005 15:46:43 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01500FB5@esebe100.NOE.Nokia.com> Thread-Topic: Updated agenda Thread-Index: AcXhRjEU/RpjP3QpRlCZP6lFEODvrg== To: X-OriginalArrivalTime: 04 Nov 2005 13:46:44.0740 (UTC) FILETIME=[31AE6440:01C5E146] X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Updated agenda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org A few small changes: WEDNESDAY, November 9, 2005 0900-1130 Morning Session I TSV nsis Next Steps in Signaling WG Agenda bashing - chair - 10 min NATFW NSLP - Martin Stiemerling - 20 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-08.txt NATFW NSLP Implementation Status - Hannes Tschofenig - 5 min Mobility Applicability Statement for NSIS - Sung-Hyuck Lee - 10 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobilit= y-signaling-03.txt GIST - Robert Hancock - 20 mins=20 http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-08.txt Analysis of Options for Securing GIST - Hannes Tschofenig - 10 min http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-gist-security-0= 0.txt Path type support for NSIS signaling - Takako Sanda - 15 min http://www.ietf.org/internet-drafts/draft-sanda-nsis-path-type-03.txt NSIS Flow ID and packet classification Issues - Cheng Hong - 15 min http://www.ietf.org/internet-drafts/draft-cheng-nsis-flowid-issues-02.txt= =20 GIST over SCTP - Xiaoming Fu - 5 min http://www.ietf.org/internet-drafts/draft-fu-nsis-ntlp-sctp-00=20 NSIS Operation Over IP Tunnels - Henning Schulzrinne - 10 min=09 http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-01.txt=20 AAA support for QoS signaling - Hannes Tschofenig - 10 min http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-05.txt http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-02.txt = =20 Metering NSLP - Jurgen Quittek- 10 min http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-02.= txt=20 http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-03.= txt=20 Design Options of NSIS Diagnostics NSLP - Xiaoming Fu - 10 min http://user.informatik.uni-goettingen.de/~fu/nsis/diagnostics/draft-fu-ns= is-diagnostics-nslp-00.txt THURSDAY, November 10, 2005 1510-1610 Afternoon Session II TSV nsis Next Steps in Signaling WG QoS-NSLP - Jukka Manner - 15 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-08.txt QSPEC I-D - Jerry Ash - 10 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt Y.1541-QOSM I-D - Jerry Ash - 5 min http://ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt. User Application-to-User Plane Vertical Interface - Jerry Ash - 5 min http://ietf.org/internet-drafts/draft-ash-nsis-vertical-interface-01.txt RMD-QOSM - Attila B=E1der - 10 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-04.txt 3GPP-QOSM - TBA - 10 min http://www.ietf.org/internet-drafts/draft-jeong-nsis-3gpp-qosm-02.txt A QoS Model for Signaling IntServ Controlled-Load Service - X. Fu - 5 = min http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlle= dload-03=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 04 09:17:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY2O0-0004rG-7e; Fri, 04 Nov 2005 09:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY2Ny-0004r8-O4 for nsis@megatron.ietf.org; Fri, 04 Nov 2005 09:17:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22538 for ; Fri, 4 Nov 2005 09:17:19 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY2cw-0008Cm-Rv for nsis@ietf.org; Fri, 04 Nov 2005 09:33:13 -0500 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id jA4EH0WA004860; Fri, 4 Nov 2005 14:17:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST: Switching to C-Mode after setup on behalf of theresponder node Date: Fri, 4 Nov 2005 14:17:00 -0000 Message-ID: Thread-Topic: [NSIS] GIST: Switching to C-Mode after setup on behalf of theresponder node Thread-Index: AcXhJWaunDeQjXHhStilHXA/oGl+1wAI14Pw From: "Hancock, Robert" To: "Thomas Herzog" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Thomas, You are right that basically this is not possible. The underlying assumption is that the querying node is always in charge of initiating things to do with messaging association policy. My expectation is that a signalling application running on a node should ensure that the GIST policies will lead to something=20 appropriate for carrying the NSLP traffic *in either direction*. After all, even though the QN NSLP doesn't know which peer it is talking to, it does at least know what NSLP it is talking to, in which case it is reasonable to require it to know about the necessary transport/security properties that it should request. I think trying to do something more sophisticated also leads to several problems (see below in line). cheers, robert h. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Thomas Herzog > Sent: 04 November 2005 09:44 > To: nsis@ietf.org > Subject: [NSIS] GIST: Switching to C-Mode after setup on=20 > behalf of theresponder node >=20 >=20 > Hi, together, >=20 > I find it very hard to install a Messaging Association on=20 > behalf of the=20 > responder node, when there is currently only D-Mode set up for the=20 > connection. Correct. >=20 > On the QN side, the QN can do so by using a refresh cycle and=20 > asking for stack=20 > proposal and switching to C-Mode by initiating a MA with the confirm. >=20 > On the RN side, GIST will get a SendMessage call from a NSLP=20 > (which needs=20 > C-Mode), find Routing State and finds out that it has only=20 > D-Mode available. >=20 > What to do now, as a Refresh cycle cannot be initiated from the RN. >=20 > A new Handshake initiated from the RN would also be quite=20 > problematic, as the=20 > QN is in some state of its QN-SM, thus it will not respond to=20 > queries for the=20 > already installed state (and will not transit into Responder Role). it may even be impossible to initiate the handshake from the 'RN' at all: this would require to send a Query, but encapsulating=20 the Query correctly for the RN->QN direction can only be done for some MRMs and then only under special circumstances. So we would=20 need to define additional query encapsulations where the destination IP address was derived from known routing state. And then the=20 routing state refresh would become problematic (because repeating the handshake would certainly not detect any route changes). >=20 > What to do in that case? >=20 > It is thinkable, that such a case happens, imagine a=20 > Responding NSLP not=20 > requiring C-Mode (as it knows, the connection is set up=20 > 'unreliable'/'insecure'), but maybe it wants to transmit a=20 > large amount of=20 > data which cannot be sent in D-Mode. see main body of email. >=20 > Wouldn't it be a good idea to include a new rule in QN-SM in State=20 > "established" to kill all state and start RN-SM if a GIST=20 > query arrives for=20 > the state? This is conceivable, but think of the denial of service implications... (and a number of other issues). >=20 > Thus a RN may "upgrade" the connection properties by initiating a new=20 > handshake, starting QN-SM and the "roles" would be swapped? A fallback case would be for the NSLP at the RN to ask its upstream peer to upgrade GIST operation. (There is a similar interaction for route change processing.) But, I still think it is easiest to make this a=20 matter of (static) NSLP policy. >=20 > Cheers, Thomas >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Nov 05 17:03:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYW8G-0002vx-IE; Sat, 05 Nov 2005 17:03:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYW8C-0002vh-A6; Sat, 05 Nov 2005 17:03:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22705; Sat, 5 Nov 2005 17:02:59 -0500 (EST) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYWNS-0004w3-ME; Sat, 05 Nov 2005 17:19:11 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-131.messagelabs.com!1131228140!647630!5 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 4330 invoked from network); 5 Nov 2005 22:03:13 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-131.messagelabs.com with SMTP; 5 Nov 2005 22:03:13 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA001E7F94; Sat, 5 Nov 2005 17:03:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Nov 2005 16:03:11 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9624@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [mpls] draft-ietf-tsvwg-diffserv-service-classes-01 starting WGLC Thread-Index: AcXg84w4o1nKZVMARuOSFcGrBfivqwBX6Iiw From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: George Swallow , "Ash, Gerald R \(Jerry\), ALABS" , "Peterson, Jon" , mpls@ietf.org, Loa Andersson , "James M. Polk" , khchan@nortel.com Subject: [NSIS] RE: [mpls] draft-ietf-tsvwg-diffserv-service-classes-01 starting WGLC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org All, FYI. This I-D http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-cl asses-01.txt is under cross-area review and of possible interest to NSIS. Also may be relevant to QSPEC, Y.1541-QOSM, 3GPP-QOSM RE mappings of service classes. Y.1541 is mentioned only once (Section 2.3), and probably should be referenced. Thanks, Jerry -----Original Message----- From: mpls-bounces@lists.ietf.org [mailto:mpls-bounces@lists.ietf.org] On Behalf Of James M. Polk Sent: Thursday, November 03, 2005 9:52 PM To: mpls@ietf.org; George Swallow; Loa Andersson Cc: jmpolk@cisco.com; Peterson, Jon; khchan@nortel.com Subject: [mpls] draft-ietf-tsvwg-diffserv-service-classes-01 starting WGLC MPLS WG The chairs of TSVWG have started a WGLC on the following ID: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-cl asses-01.txt=20 This document is being put forth as an Informational document. Because of the nature of this document, it has the potential to affect=20 other efforts outside of TSVWG's influence and/or review, therefore=20 comments are being solicited from other WGs on this document. Comments=20 regarding this document either belong on the TSVWG list, or at the very=20 least, please include all the addresses in the From and CC headers of this=20 message so we authors and chairs can track such comments. Thank you! This WGLC will end on November 18th. Allison Jon James IETF TSVWG co-chairs _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Nov 06 12:27:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoIm-0004SO-Op; Sun, 06 Nov 2005 12:27:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoIl-0004SE-J7; Sun, 06 Nov 2005 12:27:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09731; Sun, 6 Nov 2005 12:27:06 -0500 (EST) Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYoYD-00085s-1W; Sun, 06 Nov 2005 12:43:29 -0500 Received: from [134.76.81.12] (p54848DBA.dip0.t-ipconnect.de [::ffff:84.132.141.186]) (AUTH: LOGIN bschloer, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by s2.ifi.informatik.uni-goettingen.de with esmtp; Sun, 06 Nov 2005 18:27:25 +0100 id 000084CD.436E3CFD.000012FC Message-ID: <436E3CE2.6040809@cs.uni-goettingen.de> Date: Sun, 06 Nov 2005 18:26:58 +0100 From: Bernd Schloer User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org, nsis-imp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Xiaoming Fu , nsis_imp@cs.uni-goettingen.de, Tschofenig Hannes Subject: [NSIS] Release of NSIS implementation (v.0.2.0) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, we are pleased to announce the availability of the NSIS suite release 0.2, currently implementing GIST-08 I-D, draft-ietf-nsis-ntlp-statemachine-00, draft-fu-nsis-ntlp-sctp-00 and the Ping Tool "NSLP"-01, running on Linux platforms. http://user.informatik.uni-goettingen.de/~nsis/ The new version contains bug fixes and new features, like: * New improved directory structure * Support for upstream Queries * Support for LooseEnd MRM * Support for IPv6 * Support for SCTP * Support for more than one local IP address * Refactoring of GIST State Machine implementation * Introduced a configuration file * Support for Error Messages (but they are not send yet) * Renamed GIMPS to GIST * Improved NSLP API * Improved Timer Management for NSLPs * Fixed and updated message byte formats * Bug fix to support multiple connected NSLPs * Improved Debug output (new command line option -debug) * Initial documentation (file manual/Implementation) * Code cleanup * A number of small bug fixes Bernd Schloer and Christian Dickmann University of Goettingen Acknowledgments =============================================================== Thanks to all community members who contributed ideas, reported problems, provided assistance and helped us greatly to reach the status of this release. For further information =============================================================== Questions, inquiries, comments, please kindly report to the following mailing list: nsis_imp@cs.uni-goettingen.de To subscribe: send an email to nsis_imp-request@cs.uni-goettingen.de with the text subscribe YOUR-EMAIL-ADDRESS in the message body. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Nov 06 16:18:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrtr-0004M1-Tn; Sun, 06 Nov 2005 16:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrto-0004LX-Lo for nsis@megatron.ietf.org; Sun, 06 Nov 2005 16:18:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20340 for ; Sun, 6 Nov 2005 16:17:36 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYs9H-0004zA-76 for nsis@ietf.org; Sun, 06 Nov 2005 16:34:00 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jA6LHnaR022717 for ; Sun, 6 Nov 2005 22:17:49 +0100 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 jA6LHn9v029514 for ; Sun, 6 Nov 2005 22:17:49 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 6 Nov 2005 22:17:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 6 Nov 2005 22:17:48 +0100 Message-ID: Thread-Topic: slides for nsis meeting Thread-Index: AcXjFD+IaCMOuq/ZQ4u2aTE8zeA8Ew== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 06 Nov 2005 21:17:49.0000 (UTC) FILETIME=[8A103C80:01C5E317] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [NSIS] slides for nsis meeting X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all,=20 please send me your slides for the meeting. i will copy them to=20 http://www.ietf-nsis.org/nsis/IETF64/ ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 07 08:19:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6uQ-0000Lm-T8; Mon, 07 Nov 2005 08:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ6uP-0000LN-RZ for nsis@megatron.ietf.org; Mon, 07 Nov 2005 08:19:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09046 for ; Mon, 7 Nov 2005 08:19:11 -0500 (EST) Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZ7A0-0003Mf-SP for nsis@ietf.org; Mon, 07 Nov 2005 08:35:45 -0500 Received: (qmail invoked by alias); 07 Nov 2005 13:19:15 -0000 Received: from p54A31694.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.22.148] by mail.gmx.net (mp014) with SMTP; 07 Nov 2005 14:19:15 +0100 X-Authenticated: #4469397 From: Thomas Herzog To: nsis@ietf.org Date: Mon, 7 Nov 2005 14:14:41 +0100 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071414.41803.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [NSIS] GIST API: InvalidateRoutingstate setting state to "Tentative" - what use would it have? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I am currently implementing the InvalidateRoutingstate and SetStateLifetime API calls und stumbled about one thing: According to the I-D, NSLP may invalidate Routing State to "BAD" and "TENTATIVE" and also supply a "urgency" Flag, as to whether GIST should reestablish the Route instantly or if it can delay this until the next SendMessage call. In my eyes, setting state to "BAD" would be killing Routing State, so that only the SII-Handle may be used to contact the peer after that call, and the "urgency" flag would tell GIST to do a new handshake and install new Routing State for all the (MRI/SID/NSLPID) tuples the InvalidateRoutingState API call applied to. But what would the case of NSLP setting the state to "TENTATIVE" cause GIST to do? Would it cause a Routing State REFRESH, if the urgency flag is set? What happens, if the NSLP sets the state to "TENTATIVE" and not set the "urgency" flag? GIST would then only know "this routing state can be wrong" when the next SendMessage arrives, I can see no use for this case at all, can someone enlighten me? Should GIST then start a refresh on the next SendMessage call? (it would in the meantime also do Refreshes due to periodic probing...) Currently, I set the state to "TENTATIVE", when entering a Refresh cycle and to "BAD" when the state times out. "GOOD" I use when the state machine enters the "established" states. So, it would be helpful, if someone could clearify what exactly GIST is supposed to do when: - NSLP sets the state to "tentative" and provides urgency flag - NSLP sets the state to "tentative" and does not provide urgency flag Thanks in advance, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 07 08:51:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ7Pg-0006Lq-49; Mon, 07 Nov 2005 08:51:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ7Pe-0006Lh-J8 for nsis@megatron.ietf.org; Mon, 07 Nov 2005 08:51:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10462 for ; Mon, 7 Nov 2005 08:51:27 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1832YeWo8hKGwbblL+mIZWCTljHc2Mazmg=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ7fG-00048Y-D4 for nsis@ietf.org; Mon, 07 Nov 2005 09:08:02 -0500 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 1EZ7PU-0001PE-G2; Mon, 07 Nov 2005 14:51:50 +0100 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 49B71B3C2; Mon, 7 Nov 2005 14:51:44 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EZ7PT-0007ii-Tf; Mon, 07 Nov 2005 14:51:44 +0100 Message-ID: <436F5BEF.3000304@tm.uka.de> Date: Mon, 07 Nov 2005 14:51:43 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Kappler, Cornelia" Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC References: <391E6FBF5E786940B9E2F7CA6376C708DE44EF@blns00fa.ww002.siemens.net> In-Reply-To: <391E6FBF5E786940B9E2F7CA6376C708DE44EF@blns00fa.ww002.siemens.net> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) 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] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: "Ash, Gerald R \(Jerry\), ALABS" , Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cornelia, Kappler, Cornelia wrote: > (1) "stacked classfiers" as well as "each QoS model can select to use > other MRI parameters" may lead to a single QoS NSLP session reserving > resources for two or more separate flows. I'm really not in favor of stacked classifiers, but I think that there are cases when you really need a reservation for two flows, e.g., in case of a handover. But I guess that you are referring to the case when MRI and packet classifiers are "inconsistent". In my point of view the QoS model should derive the packet classifiers from the MRI. You only need to signal separate packet classifier information when it is not possible to derive the classifier settings from the MRI somehow. > This has been pointed out by several people. Obviously, this is a bad > thing. So in consequence, we should agree there is only one valid packet > classifier for a given session. I agree if you meant that there may be inconsistencies by signaling different opaque classifiers. I'm not sure that we need to signal a classifier at all. If it is signalled, one must check the packet classifier and MRI "match" somehow before blindly setting or activating the classifier. However, in case of handovers or aggregation it is likely that you need to use different classifiers for the same session (usually we have two different MRIs which describe partially overlapping flow paths). > (2) the packet classifier depends rather little on the QoS Model. > > I am aware Georgios, Roland,...said the opposite. However, I think there > is exactly one parameter in the packet classifier that to some extent is > QoS Model dependent, namely DSCP! Any DiffServ-based QoS Model is likely > to use the DSCP as a packet classifier. And if this DiffServ QoS Model > is used somewhere in the middle of a data path, whereas the QNI didnt > foresee usage of DSCP, we do have an issue. > > Vice versa however, I can imagine any other QoS Model to include the > DSCP in its packet classifier. And, checking all other parameters (IP > source / dest, etc) they are not at all QoS Model specific. Then the MRI is sufficient to derive classification information from it. My point was that the QoS model needs to determine not only the corresponding packet classifier but also any further traffic conditioning elements like markers, droppers etc. > So I think we need to rephrase the question: Should we accomodate a > scenario where a (edge) QNE is allowed to change the flow identifier > because it appears more suitable to its QoS Model? In my mind, we The confusion is here that we have two things that "identify" a flow. As far as I understood, the only reliable description for a flow is the MRI which must be carried in GIST. If you need a packet classifier it must be related to the MRI > shouldnt, because of (1). What the QNE should do in this case is tunnel > the ongoing NSIS session and set up a new one with a packet classifier > to its liking. > > (This argument implies there is no reason to place the packet classifier > in the QSPEC) I don't see this point as counter-argument against placement of a classifier into the QSPEC rather than against stacking things :-) As I said above: I'm not really sure that we need such thing at all. If not, the QoS model must derive the corresponding MRI->classifier mapping anyway. If yes, I think that it probably belongs more into the QSPEC than into the QoS-NSLP. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 07 16:21:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEQz-0002iQ-Df; Mon, 07 Nov 2005 16:21:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEQx-0002df-1L for nsis@megatron.ietf.org; Mon, 07 Nov 2005 16:21:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08615 for ; Mon, 7 Nov 2005 16:21:17 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZEga-0000dn-V5 for nsis@ietf.org; Mon, 07 Nov 2005 16:37:55 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA7LIuJi028633; Mon, 7 Nov 2005 23:18:59 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:21:36 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:21:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] TLS in the GIST draft Date: Mon, 7 Nov 2005 23:21:33 +0200 Message-ID: Thread-Topic: [NSIS] TLS in the GIST draft Thread-Index: AcXTbmmrzpaKZGvORFOnk1y3buFk+AQcsdvA To: , X-OriginalArrivalTime: 07 Nov 2005 21:21:35.0905 (UTC) FILETIME=[3BB8F110:01C5E3E1] X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Robert Hancock wrote: > hi pasi, john, all,=20 >=20 > [warning: long, dense mail]=20 > > i've had time to think about this a little. in terms of what one > could specific about TLS, there seem to be 4 (related) issues, all > of one it would be good to see some more discussion on. > > 1. TLS version. The draft currently says MUST 1.0, SHOULD 1.1. > Given that GIST will be built from TLS libraries (rather than > already deployed TLS code), maybe we could be more prescriptive > about wanting 1.1; would that be a good or bad thing? Many existing TLS libraries don't support 1.1 yet, and since the improvements in 1.1 are really minor, I don't see why we should require it. > 2. Cipher suites (raised earlier in this thread). AFAICT from > reading them, the TLS documents specify a single (mandatory to > implement) cipher suite, so TLS compliance is enough to provide > interoperability from that point of view. Is there a need to be more > prescriptive here? (Why did Diameter do so?) The mandatory-to-implement ciphersuite specified in RFC 2246 is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. This can't be used in=20 many situations because it requires certificates containing DSS public keys (most certs are RSA). TLS 1.1 changes this to TLS_RSA_WITH_3DES_EDE_CBC_SHA, which=20 is slightly better. But IMHO it is still worthwhile to clarify=20 this explicitly in the NSIS specs, especially if we do not mandate 1.1. > 3. What authentication methods (certificates, EAP, SRP, etc. etc.) > should be implemented. (Sometimes the authentication method seems to > be implied by offering a certain special ciphersuite, as in the PSK > case in particular.) The ciphersuite does imply something about the authentication, but not necessarily everything that's needed. But if we copy the Diameter text, it pretty unambiguously talks about mutual authentication using certificates. > 4. How to decide which identity is to be asserted and authenticated > (of querying and responding node > > > Even if we do stick with the NLI, there may still be a need to write > something about operational issues. That could be to encourage some > uniformity in the selection of authentication techniques, and also > (maybe) proposing a structure for the PI field in the NLI (if only > to make it human-readable). That might be for the GIST spec itself, > or (more likely?) for some separate BCP-like thing. If it's required for actual interoperability, then it IMHO needs to be in the GIST spec (or if it's a separate document, the GIST spec will need a normative reference to it)... but I guess it depends on the ambition level. It seems that for certificates, this isn't really an issue, so copying the Diameter text would be fine. Best regards, Pasi _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 09 15:06:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZwDe-00051V-09; Wed, 09 Nov 2005 15:06:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZwDd-00051Q-9U for nsis@megatron.ietf.org; Wed, 09 Nov 2005 15:06:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05318 for ; Wed, 9 Nov 2005 15:06:25 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZwTf-0008Et-5I for nsis@ietf.org; Wed, 09 Nov 2005 15:23:30 -0500 Received: from ccs (dhcp-65-64.ee.columbia.edu [128.59.65.64]) (user=qs2005 mech=LOGIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jA9K6mGM011808 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 9 Nov 2005 15:06:49 -0500 (EST) From: "Charles Shen" To: Date: Wed, 9 Nov 2005 15:06:47 -0500 Organization: Columbia University Message-ID: <001e01c5e569$1d534390$40413b80@ccs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Adding Binding_Code to QoS NSLP BOUND_SESSION_ID object X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, As described in the NSIS Operation over IP tunnels draft (http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-01.txt), the BOUND_SESSION_ID object may be used to carry the dependency of the = tunnel session and the corresponding e2e session. The BOUND_SESSION_ID object defined in QoS NSLP draft however does not indicate the nature of = session dependency. It may also be used for bi-directional flows or flow = aggregation etc. The currently defined general rule to process a message with a BOUND_SESSION_ID object (e.g. a QNE MUST copy the BOUND_SESSION_ID = object into all messages it sends for the same session.) might not fit in the tunneling context. For NSIS-tunnel operation, the dependency is = maintained by tunnel endpoints and should not be propagated further outside the tunnel. =20 Therefore we would like to know whether the WG thinks it is a good idea = to add a Binding_Code field to the current BOUND_SESSION_ID object (the = format is attached at the end of this email for reference). Thanks! Charles P.s. BOUND_SESSION_ID object with Binding_Code:=20 Type: BOUND_SESSION_ID Length: Fixed - 5 32-bit words Value: contains an 8-bit Binding_Code that indicates the nature of binding. The rest specifies the Session ID of the session that must be bound to the session associated with the message carrying this object. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Binding_Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: BOUND_SESSION_ID Object Currently defined Binding_Codes are: o 0x01 - Tunnel and end-to-end sessions o 0x02 - Bi-directional sessions o 0x03 - Aggregate sessions o 0x04 - Dependent sessions (one session is alive only if the other session is also alive) More binding codes maybe defined based on the above four atomic binding actions. It is not clear whether we need to allow more than one SESSION ID in the binding object. A BOUND_SESSION_ID object carrying the code 0x01 is called a tunnel BOUND_SESSION_ID object in the tunneling draft. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 10 12:28:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaGDa-00024H-EL; Thu, 10 Nov 2005 12:28:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaGDY-000247-KS for nsis@megatron.ietf.org; Thu, 10 Nov 2005 12:28:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20001 for ; Thu, 10 Nov 2005 12:27:39 -0500 (EST) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaGTn-0001AX-GL for nsis@ietf.org; Thu, 10 Nov 2005 12:44:56 -0500 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 10 Nov 2005 19:28:00 +0200 id 00070229.43738320.000075ED Date: Thu, 10 Nov 2005 19:28:00 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [NSIS] Diff on QoS NSLP 07 > 08 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, Just realized I hadn't sent a link to the diff of the changes between versions 07 and 08 of the QoS NSLP draft. Here it is: http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-07-08.html Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 10 13:29:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHB4-0001kV-6i; Thu, 10 Nov 2005 13:29:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHB1-0001jf-35; Thu, 10 Nov 2005 13:29:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23885; Thu, 10 Nov 2005 13:29:05 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaHRH-0002yg-1j; Thu, 10 Nov 2005 13:46:23 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BEE1E4F0004; Thu, 10 Nov 2005 19:29:25 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Nov 2005 19:27:55 +0100 Content-class: urn:content-classes:message Date: Thu, 10 Nov 2005 19:27:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: RMD & pre-congestion notification: How edge-edge and end-end can interwork Thread-Index: AcXmHqmeJ1VanX5/Tb6vf363E0uLMwABbWEA From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Georgios Karagiannis" , , , X-OriginalArrivalTime: 10 Nov 2005 18:27:55.0157 (UTC) FILETIME=[77B63C50:01C5E624] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: quoted-printable Cc: Subject: [NSIS] RE: RMD & pre-congestion notification: How edge-edge and end-end can interwork X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi All, this link may work better, Attila http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-westberg-loa= dcntr-03.txt > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Thursday, November 10, 2005 6:46 PM > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars Westberg > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny); > tsvwg@ietf.org; nsis@ietf.org > Subject: Re: RMD & pre-congestion notification: How edge-edge and > end-end can interwork >=20 >=20 >=20 > Hi Bob >=20 > Thank you for your e-mail! >=20 > Please note that during an IETF meeting in 2000, Lars=20 > Westberg presented > an Internet draft, see bellow, that used the ECN bits for edge2edge > admission control purposes, but it could not become a WG draft. >=20 > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt >=20 > Best Regards, > Georgios >=20 >=20 > On 11/10/2005, "Bob Briscoe" wrote: >=20 > >Attila, Georgios, > > > >[cross-posting tsvwg & nsis] > > > >Below is the mail I sent to you over a year ago solving your=20 > concerns over > >interworking end-end & edge-edge ECN. > > > >The similar text below has been in > > since the initial draft. > > > >As it says, if anyone can identify a genuine need to do e2e=20 > congestion > >control within a reservation, we have a way to allow it. So=20 > if you have a > >plausible reason for why anyone might ever want this, we are=20 > certainly > >willing and able to accomodate you. But do you? > > > >We don't want to complicate the system if no-one will ever=20 > need it. I can > >construct hypothetical scenarios where cc might be useful=20 > even when you > >have reserved bandwidth, but I can't think of any practical use. > > > >If your concern is purely that we should not second-guess=20 > what people might > >want in the future, you need not worry. Because if cc within=20 > a resv were > >required, a simple extension to the e2e signalling protocol=20 > (RSVP or NSIS) > >would allow the endpoints to say they wanted to use ECN=20 > end-to-end. That > >could be added if the need arose. But I don't see the need=20 > to add it now. > > > >" > >4.3. Egress gateways > > > > Egress gateways do the following tasks: > > > >---snip--- > > > > o Packet colouring - for CL packets, set the DSCP and=20 > the ECN field > > to whatever has been agreed as appropriate for the=20 > next domain. By > > default the ECN field is set to the Not-ECT=20 > codepoint. Note that > > this results in the loss of the end-to-end meaning of the ECN > > field. It can usually be assumed that end-to-end congestion > > control is unnecessary within an end-to-end=20 > reservation. But if a > > genuine need is identified for end-to-end ECN=20 > semantics within a > > reservation, then an alternative is to tunnel CL=20 > packets across > > the CL-region, or to agree an extension to end-to-end=20 > signalling > > to indicate that the microflow uses an ECN-capable=20 > transport. We > > do not recommend such apparently unnecessary complexity. > > > >" > >It's really a question of what everyone believes the default=20 > semantics of a > >reservation are today: > >a) end-to-end cc is not being used for reserved traffic? > >b) end-to-end cc is being used for reserved traffic? > > > >I believe, pragmatically, it is a). > > > >But perhaps you believe the current default position is (b)? If the > >consensus of the TSVWG or NSIS w-gs is with you not me, we=20 > would have to > >define extensions to RSVP and NSIS for the endpoints to flag=20 > that they were > >NOT intending to use end-to-end cc. To reduce complexity, I=20 > would want the > >default for the API to any new signalling stacks to be=20 > REQUIRED to be NO > >end-to-end congestion control required. > > > >Then legacy hosts that want to use end-to-end cc would not=20 > need to signal > >anything new. > >And if application writers using reservations said nothing and their > >application was installed on an operating system compliant with the > >signalling extension it would automatically signal that=20 > end-to-end cc was > >not being used. App writers who wanted to use end-to-end cc within > >reservations would have to explicitly call the API to say so. > > > >Cheers > > > > > > > >Bob > > > >>From: Attila B=E1der (IJ/ETH) > >> > >>To: "'Bob Briscoe'" > >>Cc: "Lars Westberg (KI/EAB)" , > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'"=20 > , > >> gqs@jungle.bt.co.uk > >>Subject: RE: RE: Meeting to discuss QoS > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 > >>X-Mailer: Internet Mail Service (5.5.2657.72) > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC) > >>FILETIME=3D[0F6B35F0:01C48424] > >>X-MIME-Autoconverted: from quoted-printable to 8bit by > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 > >> > >>Hi Bob, > >> > >>Thank you for your answers, I will think of them. > > > >[BB 10/11/05]: Haven't seen any response since --- until=20 > Georgios repeated > >the concern in the TSVWG mtg on Tuesday. > > > >>The work mentioned was not published, so I cannot send a=20 > ref. now. The > >>contact person knows our investigation, even if not all the details, > >>please let me know if you do not get answer from him. > >> > >>Best regards, Attila > >> > >> > -----Original Message----- > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > >> > Sent: Thursday, August 12, 2004 1:54 PM > >> > To: Attila B=E1der (IJ/ETH) > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk > >> > Subject: RE: RE: Meeting to discuss QoS > >> > > >> > > >> > Attila, > >> > > >> > Sorry for delay - been meeting a submission deadline.=20 > See below... > >> > > >> > At 15:58 06/08/04, IJ/ETH wrote: > >> > >Hi Bob, > >> > > > >> > >I apologize for the late answer, I was very busy during the > >> > summer and we > >> > >had to discuss your proposal. Yesterday we came together > >> > with Philip and > >> > >Lars for a discussion. > >> > > > >> > >We have the following main comments regarding the=20 > solutions sent us: > >> > > > >> > >We have also investigated similar solutions. > >> > > >> > [BB] Refs? > >> > > >> > >[AB] The main problem we see with ECN marking is that it has > >> > end-to-end scope. > >> > >The default behavior of ECN assumes that the end host switch > >> > on/off the > >> > >marking. > >> > > >> > [BB] We aren't using the default behaviour. I thought=20 > the paper makes this > >> > clear. It says we're using all three of the RSVP, DSCP and > >> > ECN /protocols/, > >> > but none of their /architectures/, that is, we're not using > >> > the Intserv, > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at > >> > the IP layer. > >> > The return path is an opaque object carried by the RSVP RESV > >> > from edge to > >> > edge. > >> > > >> > Traffic that has had a reservation signalled has ECT and a > >> > guaranteed DSCP > >> > turned on at the ingress gateway and turned off at the egress. > >> > > >> > Traffic not under a reservation (either not matching=20 > filterspec, or > >> > matching but overflowing the token bucket) is policed to > >> > ensure it isn't > >> > using the guaranteed DSCP. But ECT isn't touched, allowing > >> > the end systems > >> > to control how congestion is handled. > >> > > >> > We have various (unresolved) options if ECT is already on > >> > when reserved > >> > packets arrive. Obviously we leave it on at ingress, but the > >> > question is > >> > how to know not to turn it off at egress. Two possibilities: > >> > - extend the signalling to say what to do at egress (but this > >> > doesn't cope > >> > with some packets in the reservation having ECT on & others off). > >> > - tunnel between the gateways (wastes header space just to > >> > tunnel one bit) > >> > > > > >---Snip loads of further conversation--- > > > > > > > >_____________________________________________________________ > _______________ > >Notice: This contribution is the personal view of the author=20 > and does not > >necessarily reflect the technical nor commercial direction of BT plc. > >_____________________________________________________________ > _______________ > >Bob Briscoe, Networks Research=20 > Centre, BT Research > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. =20 > +44 1473 645196 > > > > >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 10 14:33:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIAd-0007th-JM; Thu, 10 Nov 2005 14:33:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIAc-0007t9-6r for nsis@megatron.ietf.org; Thu, 10 Nov 2005 14:33:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28141 for ; Thu, 10 Nov 2005 14:32:45 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIOc-0005ME-Cm for nsis@ietf.org; Thu, 10 Nov 2005 14:47:45 -0500 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id jAAJU6WA002551; Thu, 10 Nov 2005 19:30:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VGTHYFAT; Thu, 10 Nov 2005 19:35:01 -0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Date: Thu, 10 Nov 2005 19:30:01 -0000 Message-ID: <008301c5e62d$26e6bda0$b66c34d1@comm.ad.roke.co.uk> Thread-Topic: GIST Responder Cookie Generation Thread-Index: AcXmLdfSMjCY8GqRSiKhdqALy44odw== From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: nsis@ietf.org Subject: [NSIS] RE: GIST Responder Cookie Generation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1813013124==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1813013124== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E62D.D74D2080" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E62D.D74D2080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi roland, all, i've added some text on this to the relevant section in 8.5: "To support the validation simplicity requirement, the Responder can check the liveness data to filter out some blind (flooding) attacks before beginning any cryptographic cookie verification. To support this usage, the liveness data must be carried in the clear and not be easily guessable; this rules out the timestamp approach, and suggests the use of sequence of secrets with the liveness data identifying the position in the sequence. The rollover frequency of the secret must be high enough that the secret cannot be brute-forced during its lifetime. Note that any node can use a Query to discover the current liveness data, so it remains hard to defend against sophisticated attacks which disguise such 'probes' within a flood of Queries from forged source addresses. Therefore, it remains important to use an efficient hashing mechanism or equivalent." So, at the moment I think the best we get from this is some partial=20 protection (because I don't see a way to prevent an attacker extracting valid cleartext liveness data with a Query). I think it is useful, but we still need to have fast hash (or whatever) verification as part of the requirement. (unless someone can think of a better way ...) Robert H. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 24 October 2005 05:45 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: GIST Responder Cookie Generation >=20 >=20 > Hi Robert, >=20 > Hancock, Robert wrote: > > Certainly there is a case for adding the issues about > > blind attacks and strength of the secret (if secret-based > > liveness data is used) to the discussion of the cookie > > requirements. I've created=20 > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue97 > > to capture it. >=20 > Ok, thanks. >=20 > > What i'm not certain about is where to document the more > > detailed ideas about how to defend against the problems, > > e.g. rollover rate, key length and so on. ideally they'd > > be written down somewhere. but it seems to me that the >=20 > Yep. >=20 > > gist spec itself is not the best place for them: specifically, > > it would be good to allow them to evolve and be added to=20 > > rather freely, because they don't affect interoperability, >=20 > 100% agreed. That's what I meant by "(not in the sense of a too strict > specification)". Therefore I requested only to provide > additional background on the threats rather than giving > exact numbers for rollover rate or key length. These will > evolve over time and 64-bit may seem sufficient *today* > for one parameter but this setting should be adapted over > time as threats and CPUs evolve... >=20 > > whereas the spec is supposed to be (or become) stable. i'd > > like to see an implementors guide, but i'm not sure what=20 > > other people think about that. >=20 > That would be a nice thing to have, but I'm not sure what > else would go in there at the moment. >=20 > Regards, > Roland >=20 ------_=_NextPart_001_01C5E62D.D74D2080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: GIST Responder Cookie Generation

hi roland, all,

i've added some text on this to the relevant section = in 8.5:

  "To support the validation simplicity = requirement, the Responder can
   check the liveness data to filter out = some blind (flooding) attacks
   before beginning any cryptographic = cookie verification.  To support
   this usage, the liveness data must be = carried in the clear and not be
   easily guessable; this rules out the = timestamp approach, and suggests
   the use of sequence of secrets with the = liveness data identifying the
   position in the sequence.  The = rollover frequency of the secret must
   be high enough that the secret cannot be = brute-forced during its
   lifetime.  Note that any node can = use a Query to discover the current
   liveness data, so it remains hard to = defend against sophisticated
   attacks which disguise such 'probes' = within a flood of Queries from
   forged source addresses.  = Therefore, it remains important to use an
   efficient hashing mechanism or = equivalent."

So, at the moment I think the best we get from this is = some partial
protection (because I don't see a way to prevent an = attacker extracting
valid cleartext liveness data with a Query). I think = it is useful, but
we still need to have fast hash (or whatever) = verification as part of
the requirement.

(unless someone can think of a better way ...)

Robert H.

> -----Original Message-----
> From: Roland Bless [mailto:bless@tm.uka.de]
> Sent: 24 October 2005 05:45
> To: Hancock, Robert
> Cc: nsis@ietf.org
> Subject: Re: GIST Responder Cookie = Generation
>
>
> Hi Robert,
>
> Hancock, Robert wrote:
> > Certainly there is a case for adding the = issues about
> > blind attacks and strength of the secret = (if secret-based
> > liveness data is used) to the discussion of = the cookie
> > requirements. I've created
> > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue97
> > to capture it.
>
> Ok, thanks.
>
> > What i'm not certain about is where to = document the more
> > detailed ideas about how to defend against = the problems,
> > e.g. rollover rate, key length and so on. = ideally they'd
> > be written down somewhere. but it seems to = me that the
>
> Yep.
>
> > gist spec itself is not the best place for = them: specifically,
> > it would be good to allow them to evolve = and be added to
> > rather freely, because they don't affect = interoperability,
>
> 100% agreed. That's what I meant by "(not = in the sense of a too strict
> specification)". Therefore I requested only = to provide
> additional background on the threats rather than = giving
> exact numbers for rollover rate or key length. = These will
> evolve over time and 64-bit may seem sufficient = *today*
> for one parameter but this setting should be = adapted over
> time as threats and CPUs evolve...
>
> > whereas the spec is supposed to be (or = become) stable. i'd
> > like to see an implementors guide, but i'm = not sure what
> > other people think about that.
>
> That would be a nice thing to have, but I'm not = sure what
> else would go in there at the moment.
>
> Regards,
>  Roland
>

------_=_NextPart_001_01C5E62D.D74D2080-- --===============1813013124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1813013124==-- From nsis-bounces@ietf.org Thu Nov 10 17:53:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLIO-0001eU-AJ; Thu, 10 Nov 2005 17:53:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLIM-0001e0-Cd for nsis@megatron.ietf.org; Thu, 10 Nov 2005 17:53:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22516 for ; Thu, 10 Nov 2005 17:52:57 -0500 (EST) Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLYe-0007N9-Tv for nsis@ietf.org; Thu, 10 Nov 2005 18:10:17 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 22:53:12 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Nov 2005 22:53:12 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 22:53:12 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1131663191973; Thu, 10 Nov 2005 22:53:11 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.5]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id jAAMr2Dr005786; Thu, 10 Nov 2005 22:53:08 GMT Message-Id: <5.2.1.1.2.20051110223718.0439e408@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 10 Nov 2005 22:51:17 +0000 To: , From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 10 Nov 2005 22:53:12.0438 (UTC) FILETIME=[87269160:01C5E649] X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Content-Transfer-Encoding: quoted-printable Cc: Subject: [NSIS] RE: RMD & pre-congestion notification: How edge-edge and end-end can interwork X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org TSVWG & NSIS, It's been pointed out that people on these lists don't understand what my=20 original posting in this thread was about (and it bounced anyway because I= =20 was cc'ing too many people). The thread started with me replying to a point made by Georgios at the mike= =20 in TSVWG. Here's the missing context. Context ------- The thread is about a difference in approach between RMD (in NSIS) and=20 pre-congestion notification (in TSVWG). Among other differences, this one=20 is about re-marking on routers within the Diffserv region if they are=20 congested. In both cases, this re-marked traffic is measured for the aggregate=20 arriving at the egress of the Diffserv region and if above a threshold,=20 admission of new flows to that aggregate is blocked. The difference is that routers in the interior of the region re-mark=20 differently: * RMD re-marks to another Diffserv codepoint and doesn't touch the ECN=20 field. * Pre-congestion notification re-marks to the CE codepoint of ECN=20 and doesn't touch the DSCP. One of the reasons RMD didn't touch the ECN codepoint was so as not to=20 interfere with end-to-end congestion control of the *same* flow. The pre-congestion notification approach deliberately chooses to re-mark=20 the ECN field, on the grounds that it is congestion that is being=20 signalled, albeit 'pre-congestion'. The draft says we think it very unlikely that anyone will be doing=20 end-to-end congestion control as well as reserving capacity for the same=20 flow. But, we say if anyone can give a good reason why this might happen,=20 we can add mechanism to allow both at once. But we don't want to add=20 complexity for what seems only a hypothetical requirement. So now, if you're interested, you can go back to the original posting and=20 perhaps understand the context. Sorry about that. Then, I'd be interested to hear from anyone who can argue for congestion=20 control within a reserved flow. Bob PS. As well as wire protocol differences, there are important semantic=20 differences in the meaning of a re-marked packet, but we'll try to reach=20 consensus with the RMD authors on that off-line first then come back to the= =20 list with the conclusion. At 18:27 10/11/2005, IJ/ETH wrote: >Hi All, this link may work better, Attila > >http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-westberg-loadc= ntr-03.txt > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Thursday, November 10, 2005 6:46 PM > > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) > > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars Westberg > > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny); > > tsvwg@ietf.org; nsis@ietf.org > > Subject: Re: RMD & pre-congestion notification: How edge-edge and > > end-end can interwork > > > > > > > > Hi Bob > > > > Thank you for your e-mail! > > > > Please note that during an IETF meeting in 2000, Lars > > Westberg presented > > an Internet draft, see bellow, that used the ECN bits for edge2edge > > admission control purposes, but it could not become a WG draft. > > > > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt > > > > Best Regards, > > Georgios > > > > > > On 11/10/2005, "Bob Briscoe" wrote: > > > > >Attila, Georgios, > > > > > >[cross-posting tsvwg & nsis] > > > > > >Below is the mail I sent to you over a year ago solving your > > concerns over > > >interworking end-end & edge-edge ECN. > > > > > >The similar text below has been in > > > since the initial draft. > > > > > >As it says, if anyone can identify a genuine need to do e2e > > congestion > > >control within a reservation, we have a way to allow it. So > > if you have a > > >plausible reason for why anyone might ever want this, we are > > certainly > > >willing and able to accomodate you. But do you? > > > > > >We don't want to complicate the system if no-one will ever > > need it. I can > > >construct hypothetical scenarios where cc might be useful > > even when you > > >have reserved bandwidth, but I can't think of any practical use. > > > > > >If your concern is purely that we should not second-guess > > what people might > > >want in the future, you need not worry. Because if cc within > > a resv were > > >required, a simple extension to the e2e signalling protocol > > (RSVP or NSIS) > > >would allow the endpoints to say they wanted to use ECN > > end-to-end. That > > >could be added if the need arose. But I don't see the need > > to add it now. > > > > > >" > > >4.3. Egress gateways > > > > > > Egress gateways do the following tasks: > > > > > >---snip--- > > > > > > o Packet colouring - for CL packets, set the DSCP and > > the ECN field > > > to whatever has been agreed as appropriate for the > > next domain. By > > > default the ECN field is set to the Not-ECT > > codepoint. Note that > > > this results in the loss of the end-to-end meaning of the ECN > > > field. It can usually be assumed that end-to-end congestion > > > control is unnecessary within an end-to-end > > reservation. But if a > > > genuine need is identified for end-to-end ECN > > semantics within a > > > reservation, then an alternative is to tunnel CL > > packets across > > > the CL-region, or to agree an extension to end-to-end > > signalling > > > to indicate that the microflow uses an ECN-capable > > transport. We > > > do not recommend such apparently unnecessary complexity. > > > > > >" > > >It's really a question of what everyone believes the default > > semantics of a > > >reservation are today: > > >a) end-to-end cc is not being used for reserved traffic? > > >b) end-to-end cc is being used for reserved traffic? > > > > > >I believe, pragmatically, it is a). > > > > > >But perhaps you believe the current default position is (b)? If the > > >consensus of the TSVWG or NSIS w-gs is with you not me, we > > would have to > > >define extensions to RSVP and NSIS for the endpoints to flag > > that they were > > >NOT intending to use end-to-end cc. To reduce complexity, I > > would want the > > >default for the API to any new signalling stacks to be > > REQUIRED to be NO > > >end-to-end congestion control required. > > > > > >Then legacy hosts that want to use end-to-end cc would not > > need to signal > > >anything new. > > >And if application writers using reservations said nothing and their > > >application was installed on an operating system compliant with the > > >signalling extension it would automatically signal that > > end-to-end cc was > > >not being used. App writers who wanted to use end-to-end cc within > > >reservations would have to explicitly call the API to say so. > > > > > >Cheers > > > > > > > > > > > >Bob > > > > > >>From: Attila B=E1der (IJ/ETH) > > >> > > >>To: "'Bob Briscoe'" > > >>Cc: "Lars Westberg (KI/EAB)" , > > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" > > , > > >> gqs@jungle.bt.co.uk > > >>Subject: RE: RE: Meeting to discuss QoS > > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 > > >>X-Mailer: Internet Mail Service (5.5.2657.72) > > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC) > > >>FILETIME=3D[0F6B35F0:01C48424] > > >>X-MIME-Autoconverted: from quoted-printable to 8bit by > > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 > > >> > > >>Hi Bob, > > >> > > >>Thank you for your answers, I will think of them. > > > > > >[BB 10/11/05]: Haven't seen any response since --- until > > Georgios repeated > > >the concern in the TSVWG mtg on Tuesday. > > > > > >>The work mentioned was not published, so I cannot send a > > ref. now. The > > >>contact person knows our investigation, even if not all the details, > > >>please let me know if you do not get answer from him. > > >> > > >>Best regards, Attila > > >> > > >> > -----Original Message----- > > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > >> > Sent: Thursday, August 12, 2004 1:54 PM > > >> > To: Attila B=E1der (IJ/ETH) > > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; > > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk > > >> > Subject: RE: RE: Meeting to discuss QoS > > >> > > > >> > > > >> > Attila, > > >> > > > >> > Sorry for delay - been meeting a submission deadline. > > See below... > > >> > > > >> > At 15:58 06/08/04, IJ/ETH wrote: > > >> > >Hi Bob, > > >> > > > > >> > >I apologize for the late answer, I was very busy during the > > >> > summer and we > > >> > >had to discuss your proposal. Yesterday we came together > > >> > with Philip and > > >> > >Lars for a discussion. > > >> > > > > >> > >We have the following main comments regarding the > > solutions sent us: > > >> > > > > >> > >We have also investigated similar solutions. > > >> > > > >> > [BB] Refs? > > >> > > > >> > >[AB] The main problem we see with ECN marking is that it has > > >> > end-to-end scope. > > >> > >The default behavior of ECN assumes that the end host switch > > >> > on/off the > > >> > >marking. > > >> > > > >> > [BB] We aren't using the default behaviour. I thought > > the paper makes this > > >> > clear. It says we're using all three of the RSVP, DSCP and > > >> > ECN /protocols/, > > >> > but none of their /architectures/, that is, we're not using > > >> > the Intserv, > > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at > > >> > the IP layer. > > >> > The return path is an opaque object carried by the RSVP RESV > > >> > from edge to > > >> > edge. > > >> > > > >> > Traffic that has had a reservation signalled has ECT and a > > >> > guaranteed DSCP > > >> > turned on at the ingress gateway and turned off at the egress. > > >> > > > >> > Traffic not under a reservation (either not matching > > filterspec, or > > >> > matching but overflowing the token bucket) is policed to > > >> > ensure it isn't > > >> > using the guaranteed DSCP. But ECT isn't touched, allowing > > >> > the end systems > > >> > to control how congestion is handled. > > >> > > > >> > We have various (unresolved) options if ECT is already on > > >> > when reserved > > >> > packets arrive. Obviously we leave it on at ingress, but the > > >> > question is > > >> > how to know not to turn it off at egress. Two possibilities: > > >> > - extend the signalling to say what to do at egress (but this > > >> > doesn't cope > > >> > with some packets in the reservation having ECT on & others off). > > >> > - tunnel between the gateways (wastes header space just to > > >> > tunnel one bit) > > >> > > > > > > >---Snip loads of further conversation--- > > > > > > > > > > > >_____________________________________________________________ > > _______________ > > >Notice: This contribution is the personal view of the author > > and does not > > >necessarily reflect the technical nor commercial direction of BT plc. > > >_____________________________________________________________ > > _______________ > > >Bob Briscoe, Networks Research > > Centre, BT Research > > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > > +44 1473 645196 > > > > > > > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 10 18:11:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLZz-000877-9o; Thu, 10 Nov 2005 18:11:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLZx-00086H-H6 for nsis@megatron.ietf.org; Thu, 10 Nov 2005 18:11:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23695 for ; Thu, 10 Nov 2005 18:11:08 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1++of/2s3mpq+DcPzdqKPFvgQtCowm3CU8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLqF-0007td-Ew for nsis@ietf.org; Thu, 10 Nov 2005 18:28:28 -0500 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 1EaLZ0-0000Y3-EK; Fri, 11 Nov 2005 00:10:41 +0100 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 583D0B54A; Fri, 11 Nov 2005 00:10:25 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EaLYm-0006Dq-LM; Fri, 11 Nov 2005 00:10:25 +0100 Message-ID: <4373D35F.4080807@tm.uka.de> Date: Fri, 11 Nov 2005 00:10:23 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" References: <008301c5e62d$26e6bda0$b66c34d1@comm.ad.roke.co.uk> In-Reply-To: <008301c5e62d$26e6bda0$b66c34d1@comm.ad.roke.co.uk> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) 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.0 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: [NSIS] Re: GIST Responder Cookie Generation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, > i've added some text on this to the relevant section in 8.5: [and this is a quite good proposal...] > "To support the validation simplicity requirement, the Responder can > check the liveness data to filter out some blind (flooding) attacks > before beginning any cryptographic cookie verification. To support > this usage, the liveness data must be carried in the clear and not be > easily guessable; this rules out the timestamp approach, and suggests > the use of sequence of secrets with the liveness data identifying the > position in the sequence. The rollover frequency of the secret must > be high enough that the secret cannot be brute-forced during its ...and thus the secret must be long enough, too > lifetime. Note that any node can use a Query to discover the current > liveness data, so it remains hard to defend against sophisticated > attacks which disguise such 'probes' within a flood of Queries from > forged source addresses. Therefore, it remains important to use an Nodes that send queries from spoofed source addresses will not succeed in discovering the liveness data, so I'm a little bit confused here. If an attacker has the liveness data, he can send a lot of Confirms whose cookies must be checked. In this case the hash function must be efficient in order to avoid an attack on CPU resources. An attack on state resources by sending a lot of Confirms will still not be possible. > efficient hashing mechanism or equivalent." > So, at the moment I think the best we get from this is some partial > protection (because I don't see a way to prevent an attacker extracting Yep. > valid cleartext liveness data with a Query). I think it is useful, but No, there is no way to prevent that. But I think this is probably not a serious problem since the attacking node must be reachable. In summary we have two lines of defense: 1. cookies against attackers that try to exhaust state resources by sending from spoofed addresses (also a blind attacker) 2. liveness data against blind attacks trying to exhaust CPU resources by letting the responder perform cookie validity checks for confirm messages. > we still need to have fast hash (or whatever) verification as part of > the requirement. > > (unless someone can think of a better way ...) Yes, input welcome. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 10 18:12:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLai-0000Vv-HX; Thu, 10 Nov 2005 18:12:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLah-0000Vq-5q for nsis@megatron.ietf.org; Thu, 10 Nov 2005 18:12:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23780 for ; Thu, 10 Nov 2005 18:11:54 -0500 (EST) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLqz-0007vf-PN for nsis@ietf.org; Thu, 10 Nov 2005 18:29:14 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id jAANBib4000370; Fri, 11 Nov 2005 08:11:44 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id jAANBjh19693; Fri, 11 Nov 2005 08:11:45 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id jAANBiA25086; Fri, 11 Nov 2005 08:11:44 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Adding Binding_Code to QoS NSLP BOUND_SESSION_ID object Date: Fri, 11 Nov 2005 07:08:57 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD7C4FDE@pslexc01.psl.local> Thread-topic: [NSIS] Adding Binding_Code to QoS NSLP BOUND_SESSION_ID object Thread-Index: AcXlaQUXtIZRybqPSCGusX09gu8H7QA4j3zw From: "Cheng Hong" To: "Charles Shen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Charles, I think this code is a good idea. It is especially useful when the aggregation and bi-direction binding exists over the same section. cheers Cheng Hong=20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Charles Shen > Sent: Thursday, November 10, 2005 4:07 AM > To: nsis@ietf.org > Subject: [NSIS] Adding Binding_Code to QoS NSLP=20 > BOUND_SESSION_ID object=20 >=20 > Hi all, >=20 > As described in the NSIS Operation over IP tunnels draft=20 > (http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-01 > .txt), the BOUND_SESSION_ID object may be used to carry the=20 > dependency of the tunnel session and the corresponding e2e=20 > session. The BOUND_SESSION_ID object defined in QoS NSLP=20 > draft however does not indicate the nature of session=20 > dependency. It may also be used for bi-directional flows or=20 > flow aggregation etc. The currently defined general rule to=20 > process a message with a BOUND_SESSION_ID object (e.g. a QNE=20 > MUST copy the BOUND_SESSION_ID object into all messages it=20 > sends for the same session.) might not fit in the tunneling=20 > context. For NSIS-tunnel operation, the dependency is=20 > maintained by tunnel endpoints and should not be propagated=20 > further outside the tunnel. =20 >=20 > Therefore we would like to know whether the WG thinks it is a=20 > good idea to add a Binding_Code field to the current=20 > BOUND_SESSION_ID object (the format is attached at the end of=20 > this email for reference). >=20 > Thanks! >=20 > Charles >=20 >=20 > P.s. BOUND_SESSION_ID object with Binding_Code:=20 >=20 > Type: BOUND_SESSION_ID >=20 > Length: Fixed - 5 32-bit words >=20 > Value: contains an 8-bit Binding_Code that indicates the nature of > binding. The rest specifies the Session ID of the session=20 > that must > be bound to the session associated with the message carrying this > object. >=20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RESERVED | =20 > Binding_Code | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | =20 > | > + =20 > + > | =20 > | > + Session ID =20 > + > | =20 > | > + =20 > + > | =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 > Figure 1: BOUND_SESSION_ID Object >=20 > Currently defined Binding_Codes are: >=20 > o 0x01 - Tunnel and end-to-end sessions > o 0x02 - Bi-directional sessions > o 0x03 - Aggregate sessions > o 0x04 - Dependent sessions (one session is alive only if=20 > the other > session is also alive) >=20 > More binding codes maybe defined based on the above four atomic > binding actions. It is not clear whether we need to allow=20 > more than > one SESSION ID in the binding object. >=20 > A BOUND_SESSION_ID object carrying the code 0x01 is called a=20 > tunnel BOUND_SESSION_ID object in the tunneling draft. >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 10 18:29:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLrE-0005j9-3D; Thu, 10 Nov 2005 18:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLrC-0005j1-Hu for nsis@megatron.ietf.org; Thu, 10 Nov 2005 18:29:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24686 for ; Thu, 10 Nov 2005 18:28:57 -0500 (EST) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaM7U-0008M3-Hp for nsis@ietf.org; Thu, 10 Nov 2005 18:46:18 -0500 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id jAANSpWA016742; Thu, 10 Nov 2005 23:28:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VGTHYFA5; Thu, 10 Nov 2005 23:33:43 -0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Date: Thu, 10 Nov 2005 23:28:36 -0000 Message-ID: <00ed01c5e64e$8025b6c0$b66c34d1@comm.ad.roke.co.uk> Thread-Topic: GIST Responder Cookie Generation Thread-Index: AcXmTzEdFLLpmD8OR+GQuoSdbKW4bw== From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.8 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: nsis@ietf.org Subject: [NSIS] RE: GIST Responder Cookie Generation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1856350027==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1856350027== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E64F.2FE0E580" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E64F.2FE0E580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi roland, the attack method i am thinking of is: - node A sends a valid Query (from its real address), but does not follow up with a Confirm - at the same time, node A sends many valid Queries (from forged addresses) at this point, node A knows some valid liveness data (from the Response to the first Query), but the 'victim' node has no idea about the location of node A, since it has no idea which Query was the useful one. (And it is probably trying to not remember information about Query messages anyway.) now node A floods the victim with Confirm messages from forged source addresses. They have valid liveness data. i don't see an easy defence against such an attack. r. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 10 November 2005 15:10 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: GIST Responder Cookie Generation >=20 >=20 > Hi Robert, >=20 >=20 > > i've added some text on this to the relevant section in 8.5: >=20 > [and this is a quite good proposal...] >=20 > > "To support the validation simplicity requirement, the=20 > Responder can > > check the liveness data to filter out some blind=20 > (flooding) attacks > > before beginning any cryptographic cookie verification. =20 > To support > > this usage, the liveness data must be carried in the=20 > clear and not be > > easily guessable; this rules out the timestamp approach,=20 > and suggests > > the use of sequence of secrets with the liveness data=20 > identifying the > > position in the sequence. The rollover frequency of the=20 > secret must > > be high enough that the secret cannot be brute-forced during its >=20 > ...and thus the secret must be long enough, too >=20 > > lifetime. Note that any node can use a Query to=20 > discover the current > > liveness data, so it remains hard to defend against sophisticated > > attacks which disguise such 'probes' within a flood of=20 > Queries from > > forged source addresses. Therefore, it remains=20 > important to use an >=20 > Nodes that send queries from spoofed source addresses will=20 > not succeed in > discovering the liveness data, so I'm a little bit confused here. > If an attacker has the liveness data, he can send a lot of Confirms > whose cookies must be checked. In this case the hash function must be > efficient in order to avoid an attack on CPU resources. An attack > on state resources by sending a lot of Confirms will still not be > possible. >=20 > > efficient hashing mechanism or equivalent." >=20 > > So, at the moment I think the best we get from this is some partial=20 > > protection (because I don't see a way to prevent an=20 > attacker extracting >=20 > Yep. >=20 > > valid cleartext liveness data with a Query). I think it is=20 > useful, but >=20 > No, there is no way to prevent that. But I think this is probably not > a serious problem since the attacking node must be reachable. > In summary we have two lines of defense: > 1. cookies against attackers that try to exhaust state resources > by sending from spoofed addresses (also a blind attacker) > 2. liveness data against blind attacks trying to exhaust CPU resources > by letting the responder perform cookie validity checks for > confirm messages. >=20 >=20 > > we still need to have fast hash (or whatever) verification=20 > as part of > > the requirement. > >=20 > > (unless someone can think of a better way ...) >=20 > Yes, input welcome. >=20 > Regards, > Roland >=20 ------_=_NextPart_001_01C5E64F.2FE0E580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: GIST Responder Cookie Generation

hi roland,

the attack method i am thinking of is:

- node A sends a valid Query (from its real address), = but does
not follow up with a Confirm
- at the same time, node A sends many valid Queries = (from forged
addresses)

at this point, node A knows some valid liveness data = (from the
Response to the first Query), but the 'victim' node = has no idea
about the location of node A, since it has no idea = which Query
was the useful one. (And it is probably trying to not = remember
information about Query messages anyway.)

now node A floods the victim with Confirm messages = from forged
source addresses. They have valid liveness = data.

i don't see an easy defence against such an = attack.

r.

> -----Original Message-----
> From: Roland Bless [mailto:bless@tm.uka.de]
> Sent: 10 November 2005 15:10
> To: Hancock, Robert
> Cc: nsis@ietf.org
> Subject: Re: GIST Responder Cookie = Generation
>
>
> Hi Robert,
>
>
> > i've added some text on this to the = relevant section in 8.5:
>
> [and this is a quite good proposal...]
>
> >   "To support the validation = simplicity requirement, the
> Responder can
> >    check the liveness data = to filter out some blind
> (flooding) attacks
> >    before beginning any = cryptographic cookie verification. 
> To support
> >    this usage, the liveness = data must be carried in the
> clear and not be
> >    easily guessable; this = rules out the timestamp approach,
> and suggests
> >    the use of sequence of = secrets with the liveness data
> identifying the
> >    position in the = sequence.  The rollover frequency of the
> secret must
> >    be high enough that the = secret cannot be brute-forced during its
>
> ...and thus the secret must be long enough, = too
>
> >    lifetime.  Note that = any node can use a Query to
> discover the current
> >    liveness data, so it = remains hard to defend against sophisticated
> >    attacks which disguise = such 'probes' within a flood of
> Queries from
> >    forged source = addresses.  Therefore, it remains
> important to use an
>
> Nodes that send queries from spoofed source = addresses will
> not succeed in
> discovering the liveness data, so I'm a little = bit confused here.
> If an attacker has the liveness data, he can = send a lot of Confirms
> whose cookies must be checked. In this case the = hash function must be
> efficient in order to avoid an attack on CPU = resources. An attack
> on state resources by sending a lot of Confirms = will still not be
> possible.
>
> >    efficient hashing = mechanism or equivalent."
>
> > So, at the moment I think the best we get = from this is some partial
> > protection (because I don't see a way to = prevent an
> attacker extracting
>
> Yep.
>
> > valid cleartext liveness data with a = Query). I think it is
> useful, but
>
> No, there is no way to prevent that. But I think = this is probably not
> a serious problem since the attacking node must = be reachable.
> In summary we have two lines of defense:
> 1. cookies against attackers that try to exhaust = state resources
>    by sending from spoofed = addresses (also a blind attacker)
> 2. liveness data against blind attacks trying to = exhaust CPU resources
>    by letting the responder = perform cookie validity checks for
>    confirm messages.
>
>
> > we still need to have fast hash (or = whatever) verification
> as part of
> > the requirement.
> >
> > (unless someone can think of a better way = ...)
>
> Yes, input welcome.
>
> Regards,
>  Roland
>

------_=_NextPart_001_01C5E64F.2FE0E580-- --===============1856350027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1856350027==-- From nsis-bounces@ietf.org Thu Nov 10 19:22:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaMgF-00043C-DR; Thu, 10 Nov 2005 19:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaMgD-000435-6j for nsis@megatron.ietf.org; Thu, 10 Nov 2005 19:22:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27431 for ; Thu, 10 Nov 2005 19:21:39 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+CymLyZT/3trkMFtGSlALRDk7iAgv4FjM=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaMwV-0001F6-Nt for nsis@ietf.org; Thu, 10 Nov 2005 19:39:01 -0500 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 1EaMg7-0003RI-Ms; Fri, 11 Nov 2005 01:22:06 +0100 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 ADB76B52A; Fri, 11 Nov 2005 01:22:02 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EaMg6-0006IN-6E; Fri, 11 Nov 2005 01:22:02 +0100 Message-ID: <4373E429.40705@tm.uka.de> Date: Fri, 11 Nov 2005 01:22:01 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" References: <00ed01c5e64e$8025b6c0$b66c34d1@comm.ad.roke.co.uk> In-Reply-To: <00ed01c5e64e$8025b6c0$b66c34d1@comm.ad.roke.co.uk> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.3 (----) 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.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: [NSIS] Re: GIST Responder Cookie Generation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, > the attack method i am thinking of is: thanks for explaining this in more detail, maybe I'm up too late now... :-) > - node A sends a valid Query (from its real address), but does > not follow up with a Confirm Ok. > - at the same time, node A sends many valid Queries (from forged > addresses) Why is this required? > at this point, node A knows some valid liveness data (from the > Response to the first Query), but the 'victim' node has no idea Yep. > about the location of node A, since it has no idea which Query > was the useful one. (And it is probably trying to not remember > information about Query messages anyway.) I assume the latter case, i.e. late state installation. > now node A floods the victim with Confirm messages from forged > source addresses. They have valid liveness data. > > i don't see an easy defence against such an attack. You are right. In this case, however, only CPU resources are consumed by hashing PDU data and the secret. That's why you require a fast cookie check function. Anyway no state gets installed. This attack can be detected though, because you get a high number of invalid confirms with correct liveness data. In this case you can increase the generation rate of the secrets (this is also mentioned in the ikev2 draft as "if under attack" IIRC). Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 10 20:09:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaNQV-0000kh-Q8; Thu, 10 Nov 2005 20:09:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaNQU-0000kX-K1 for nsis@megatron.ietf.org; Thu, 10 Nov 2005 20:09:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29573 for ; Thu, 10 Nov 2005 20:09:30 -0500 (EST) From: jmanner@cs.helsinki.fi Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaNgn-0002LI-6T for nsis@ietf.org; Thu, 10 Nov 2005 20:26:50 -0500 Received: from sbz-12.cs.helsinki.fi (sbz-12.cs.helsinki.fi [128.214.9.76]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 11 Nov 2005 03:09:54 +0200 id 00070176.4373EF62.000018BA Received: from sbz-12.cs.helsinki.fi (localhost [127.0.0.1]) by sbz-12.cs.helsinki.fi (8.12.8/8.12.8) with ESMTP id jAB19slm000516; Fri, 11 Nov 2005 03:09:54 +0200 Received: (from www@localhost) by sbz-12.cs.helsinki.fi (8.12.8/8.12.8/Submit) id jAB19d7D000515; Fri, 11 Nov 2005 03:09:39 +0200 Date: Fri, 11 Nov 2005 03:09:39 +0200 X-Authentication-Warning: sbz-12.cs.helsinki.fi: www set sender to jmanner@cs.helsinki.fi using -f To: Hong.Cheng@sg.panasonic.com, charles@cs.columbia.edu, nsis@ietf.org Subject: RE: [NSIS] Adding Binding_Code to QoS NSLP BOUND_SESSION_ID object Received: from 209.52.104.183 (auth. user jmanner@courier) by iloha.cs.Helsinki.FI with HTTP; Fri, 11 Nov 2005 03:09:39 +0200 X-IlohaMail-Blah: jmanner@cs.helsinki.fi X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.12+pk-7 (On: iloha.cs.Helsinki.FI) In-Reply-To: <5F09D220B62F79418461A978CA0921BD7C4FDE@pslexc01.psl.local> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.4 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I also supported this in my presentation today. We'll include it in the next version of the draft. Yet, I'd like to make a slight change to it. Allocate more than 8-bits for the code, eg. 16 bits. Why only use 8 bits and leave 24 bits unused? Jukka On 11/11/2005, "Cheng Hong" wrote: > Hi Charles, >=20 > I think this code is a good idea. It is especially useful when the > aggregation and bi-direction binding exists over the same section. >=20 > cheers >=20 > Cheng Hong=20 >=20 > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > > Behalf Of Charles Shen > > Sent: Thursday, November 10, 2005 4:07 AM > > To: nsis@ietf.org > > Subject: [NSIS] Adding Binding_Code to QoS NSLP=20 > > BOUND_SESSION_ID object=20 > >=20 > > Hi all, > >=20 > > As described in the NSIS Operation over IP tunnels draft=20 > > (http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-01 > > .txt), the BOUND_SESSION_ID object may be used to carry the=20 > > dependency of the tunnel session and the corresponding e2e=20 > > session. The BOUND_SESSION_ID object defined in QoS NSLP=20 > > draft however does not indicate the nature of session=20 > > dependency. It may also be used for bi-directional flows or=20 > > flow aggregation etc. The currently defined general rule to=20 > > process a message with a BOUND_SESSION_ID object (e.g. a QNE=20 > > MUST copy the BOUND_SESSION_ID object into all messages it=20 > > sends for the same session.) might not fit in the tunneling=20 > > context. For NSIS-tunnel operation, the dependency is=20 > > maintained by tunnel endpoints and should not be propagated=20 > > further outside the tunnel. =20 > >=20 > > Therefore we would like to know whether the WG thinks it is a=20 > > good idea to add a Binding_Code field to the current=20 > > BOUND_SESSION_ID object (the format is attached at the end of=20 > > this email for reference). > >=20 > > Thanks! > >=20 > > Charles > >=20 > >=20 > > P.s. BOUND_SESSION_ID object with Binding_Code:=20 > >=20 > > Type: BOUND_SESSION_ID > >=20 > > Length: Fixed - 5 32-bit words > >=20 > > Value: contains an 8-bit Binding_Code that indicates the nature of > > binding. The rest specifies the Session ID of the session=20 > > that must > > be bound to the session associated with the message carrying this > > object. > >=20 > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RESERVED | =20 > > Binding_Code | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | =20 > > | > > + =20 > > + > > | =20 > > | > > + Session ID =20 > > + > > | =20 > > | > > + =20 > > + > > | =20 > > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > >=20 > >=20 > > Figure 1: BOUND_SESSION_ID Object > >=20 > > Currently defined Binding_Codes are: > >=20 > > o 0x01 - Tunnel and end-to-end sessions > > o 0x02 - Bi-directional sessions > > o 0x03 - Aggregate sessions > > o 0x04 - Dependent sessions (one session is alive only if=20 > > the other > > session is also alive) > >=20 > > More binding codes maybe defined based on the above four atomic > > binding actions. It is not clear whether we need to allow=20 > > more than > > one SESSION ID in the binding object. > >=20 > > A BOUND_SESSION_ID object carrying the code 0x01 is called a=20 > > tunnel BOUND_SESSION_ID object in the tunneling draft. > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 10 21:34:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaOkf-0001Ft-BK; Thu, 10 Nov 2005 21:34:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaOkd-0001Bm-Sz for nsis@megatron.ietf.org; Thu, 10 Nov 2005 21:34:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04561 for ; Thu, 10 Nov 2005 21:34:23 -0500 (EST) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaP0y-0004av-Mu for nsis@ietf.org; Thu, 10 Nov 2005 21:51:45 -0500 Received: from ccs (dhcp-65-64.ee.columbia.edu [128.59.65.64]) (user=qs2005 mech=LOGIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jAB2YXX7025310 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Nov 2005 21:34:42 -0500 (EST) From: "Charles Shen" To: , , Subject: RE: [NSIS] Adding Binding_Code to QoS NSLP BOUND_SESSION_ID object Date: Thu, 10 Nov 2005 21:34:32 -0500 Organization: Columbia University Message-ID: <008a01c5e668$799a9bd0$40413b80@ccs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi My initial thought is that 8-bit seems to be sufficient to cover the few atomic actions we are currently talking about, as well as their possible combinations. So the rest of the space may be left for whatever other extensions. But I don't have strong opinion over whether 8 bit or 16 bit should be chosen at this point. Thanks. Charles > -----Original Message----- > From: jmanner@cs.helsinki.fi [mailto:jmanner@cs.helsinki.fi] > Sent: Thursday, November 10, 2005 8:10 PM > To: Hong.Cheng@sg.panasonic.com; charles@cs.columbia.edu; > nsis@ietf.org > Subject: RE: [NSIS] Adding Binding_Code to QoS NSLP > BOUND_SESSION_ID object > > > > Hi, > > I also supported this in my presentation today. We'll include > it in the next version of the draft. Yet, I'd like to make a > slight change to it. Allocate more than 8-bits for the code, > eg. 16 bits. Why only use 8 bits and leave 24 bits unused? > > Jukka > > On 11/11/2005, "Cheng Hong" wrote: > > Hi Charles, > > > > I think this code is a good idea. It is especially useful when the > > aggregation and bi-direction binding exists over the same section. > > > > cheers > > > > Cheng Hong > > > > > -----Original Message----- > > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > > Behalf Of Charles Shen > > > Sent: Thursday, November 10, 2005 4:07 AM > > > To: nsis@ietf.org > > > Subject: [NSIS] Adding Binding_Code to QoS NSLP > > > BOUND_SESSION_ID object > > > > > > Hi all, > > > > > > As described in the NSIS Operation over IP tunnels draft > > > (http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-01 > > > .txt), the BOUND_SESSION_ID object may be used to carry the > > > dependency of the tunnel session and the corresponding e2e > > > session. The BOUND_SESSION_ID object defined in QoS NSLP > > > draft however does not indicate the nature of session > > > dependency. It may also be used for bi-directional flows or > > > flow aggregation etc. The currently defined general rule to > > > process a message with a BOUND_SESSION_ID object (e.g. a QNE > > > MUST copy the BOUND_SESSION_ID object into all messages it > > > sends for the same session.) might not fit in the tunneling > > > context. For NSIS-tunnel operation, the dependency is > > > maintained by tunnel endpoints and should not be propagated > > > further outside the tunnel. > > > > > > Therefore we would like to know whether the WG thinks it is a > > > good idea to add a Binding_Code field to the current > > > BOUND_SESSION_ID object (the format is attached at the end of > > > this email for reference). > > > > > > Thanks! > > > > > > Charles > > > > > > > > > P.s. BOUND_SESSION_ID object with Binding_Code: > > > > > > Type: BOUND_SESSION_ID > > > > > > Length: Fixed - 5 32-bit words > > > > > > Value: contains an 8-bit Binding_Code that indicates > the nature of > > > binding. The rest specifies the Session ID of the session > > > that must > > > be bound to the session associated with the message > carrying this > > > object. > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | RESERVED | > > > Binding_Code | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | > > > | > > > + > > > + > > > | > > > | > > > + Session ID > > > + > > > | > > > | > > > + > > > + > > > | > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > Figure 1: BOUND_SESSION_ID Object > > > > > > Currently defined Binding_Codes are: > > > > > > o 0x01 - Tunnel and end-to-end sessions > > > o 0x02 - Bi-directional sessions > > > o 0x03 - Aggregate sessions > > > o 0x04 - Dependent sessions (one session is alive only if > > > the other > > > session is also alive) > > > > > > More binding codes maybe defined based on the above four atomic > > > binding actions. It is not clear whether we need to allow > > > more than > > > one SESSION ID in the binding object. > > > > > > A BOUND_SESSION_ID object carrying the code 0x01 is called a > > > tunnel BOUND_SESSION_ID object in the tunneling draft. > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 11 03:20:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaU9A-0004vA-Hd; Fri, 11 Nov 2005 03:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaU98-0004v5-ES for nsis@megatron.ietf.org; Fri, 11 Nov 2005 03:20:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22276 for ; Fri, 11 Nov 2005 03:20:02 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18+jg/fx8CA/yshpNNoDvBL3Wpn4tWmwJQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaUPV-00051T-9f for nsis@ietf.org; Fri, 11 Nov 2005 03:37:26 -0500 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 1EaU8j-0004U0-3U; Fri, 11 Nov 2005 09:20:10 +0100 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 DDAEBB47E; Fri, 11 Nov 2005 09:20:04 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EaU8i-0007GW-GG; Fri, 11 Nov 2005 09:20:04 +0100 Message-ID: <43745434.20404@tm.uka.de> Date: Fri, 11 Nov 2005 09:20:04 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] Re: GIST Responder Cookie Generation References: <00ed01c5e64e$8025b6c0$b66c34d1@comm.ad.roke.co.uk> <4373E429.40705@tm.uka.de> In-Reply-To: <4373E429.40705@tm.uka.de> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.3 (----) 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.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, >>- at the same time, node A sends many valid Queries (from forged >>addresses) > > > Why is this required? After some sleep things are becoming clearer ;-) You mean that node A is hiding its real address in the bulk of Queries with spoofed addresses => some kind of masquerading. Node A can even try to guess the rollover rate if it sends several Queries from its real address between a bulk of spoofed Queries. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 11 03:45:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaUX7-0004xN-2i; Fri, 11 Nov 2005 03:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaUX5-0004xF-5R for nsis@megatron.ietf.org; Fri, 11 Nov 2005 03:45:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23838 for ; Fri, 11 Nov 2005 03:44:46 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+ejm9s81vJ6oFcKlbq9LJFob83K2wkSko=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaUnT-0005mH-0k for nsis@ietf.org; Fri, 11 Nov 2005 04:02:11 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1EaUWp-0007Ts-Ay; Fri, 11 Nov 2005 09:45:06 +0100 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 1895FB47E; Fri, 11 Nov 2005 09:44:29 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1EaUWK-0007H7-OE; Fri, 11 Nov 2005 09:44:28 +0100 Message-ID: <437459EC.2010409@tm.uka.de> Date: Fri, 11 Nov 2005 09:44:28 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Charles Shen Subject: Re: [NSIS] Adding Binding_Code to QoS NSLP BOUND_SESSION_ID object References: <001e01c5e569$1d534390$40413b80@ccs> In-Reply-To: <001e01c5e569$1d534390$40413b80@ccs> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.1 (---) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5003] -1.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Charles, > Therefore we would like to know whether the WG thinks it is a good idea to > add a Binding_Code field to the current BOUND_SESSION_ID object (the format > is attached at the end of this email for reference). Yes, I think its a good idea to have that, so I support this proposal. > o 0x01 - Tunnel and end-to-end sessions If the same session is tunneled several times (and nested) then a tunnel session is bound to another tunnel session rather than to an end-to-end session. I don't think that we need a different codepoint for that, but otherwise the description may be interpreted to limit the use of 0x01 for the particular case of tunneling a normal end-to-end session. > o 0x02 - Bi-directional sessions Does 0x02 include the semantics of 0x04? :-) > o 0x03 - Aggregate sessions > o 0x04 - Dependent sessions (one session is alive only if the other > session is also alive) Hmm, 0x04 seems obvious, but may have issues. I've thought several times about interdepencies of flows within a session or handover of multiple sessions and came to the conclusion that this is a good case to apply the end-to-end argument. That means: instead of letting the network know any logical relations between flows (or sessions in this context) the network should not be aware of them. Why? Because in case of a failure of one flow (or session) you must specify how the network reacts in this case. Usually there are too many options that applications may require so that it's not good (because too complex) to put that intelligence into the network to cover every possible behavior desired by various applications. Applying the e2e would lead to the conclusion that every application should decide by itself which flows/sessions should be maintained is case some flows/sessions are affected by failures. Now 0x04 is a simple AND relationship between sessions, but then we have to specify exactly how the nodes behave in case one session is affected by a failure: is the other session explicitly torn down then (which is implied by the predicate that 0x04 defines)? Or is it only a hint for the network that sessions are dependent, but no special action is taken? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 11 06:31:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaX8L-00055a-Cn; Fri, 11 Nov 2005 06:31:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaX8J-000538-2O for nsis@megatron.ietf.org; Fri, 11 Nov 2005 06:31:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01935 for ; Fri, 11 Nov 2005 06:31:21 -0500 (EST) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaXOf-0001Xx-3W for nsis@ietf.org; Fri, 11 Nov 2005 06:48:48 -0500 Received: (qmail invoked by alias); 11 Nov 2005 11:31:35 -0000 Received: from p54A32E58.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.46.88] by mail.gmx.net (mp019) with SMTP; 11 Nov 2005 12:31:35 +0100 X-Authenticated: #4469397 From: Thomas Herzog To: nsis@ietf.org Date: Fri, 11 Nov 2005 12:27:00 +0100 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511111227.00761.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [NSIS] End node detection in GIST for Messages relayed on behalf of the NSLP? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, together, as a result of having implemented the GIST level relaying on behalf of the NSLP, it occured to me, that if we are on the End Node of the flow and NSLP would indicate to "relay", the message would basically "cycle", i.e. the NSLP would get it delivered again and again. (if it is the actual flow endpoint, if it is the last GIST hop and the flow endpoint is not GIST-aware, it would simply be lost) Is a NSLP supposed to do no such nonsense (it should know it is the end node), or is GIST supposed to do End Node detection in this case also (as it does for pure GIST relaying if there is no NSLP for the message)? GIST could do End Node detection and provide a MessageStatus for the message, but there is no status code defined yet for such an event. Or GIST could deliver the message again (being relayed to itself, it will come back) and NSLP could then detect that it is the actual End Node by the fact of receiving a already relayed Message? Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 11 10:11:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaaZ5-0002pc-Pd; Fri, 11 Nov 2005 10:11:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEpb-0002JQ-Rk for nsis@megatron.ietf.org; Thu, 10 Nov 2005 10:59:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12409 for ; Thu, 10 Nov 2005 10:58:51 -0500 (EST) Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaF5q-0006H0-RH for nsis@ietf.org; Thu, 10 Nov 2005 11:16:07 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 15:59:03 +0000 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Nov 2005 15:59:02 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 15:59:01 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1131638340355; Thu, 10 Nov 2005 15:59:00 +0000 Received: from mut.jungle.bt.co.uk ([10.86.16.70]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id jAAFwkDr027331; Thu, 10 Nov 2005 15:58:54 GMT Message-Id: <5.2.1.1.2.20051110135946.03a7ac40@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 10 Nov 2005 15:58:45 +0000 To: Attila =?iso-8859-1?Q?B=E1der?= (IJ/ETH) , karagian@cs.utwente.nl From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 10 Nov 2005 15:59:01.0379 (UTC) FILETIME=[AAC3E530:01C5E60F] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 11 Nov 2005 10:11:42 -0500 Cc: "Lars Westberg \(KI/EAB\)" , tsvwg@ietf.org, nsis@ietf.org, philip.eardley@bt.com, Kwok-Ho Chan , Jozef Babiarz , "Anna Charny \(acharny\)" Subject: [NSIS] RMD & pre-congestion notification: How edge-edge and end-end can interwork X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Attila, Georgios, [cross-posting tsvwg & nsis] Below is the mail I sent to you over a year ago solving your concerns over= =20 interworking end-end & edge-edge ECN. The similar text below has been in=20 since the initial draft. As it says, if anyone can identify a genuine need to do e2e congestion=20 control within a reservation, we have a way to allow it. So if you have a=20 plausible reason for why anyone might ever want this, we are certainly=20 willing and able to accomodate you. But do you? We don't want to complicate the system if no-one will ever need it. I can=20 construct hypothetical scenarios where cc might be useful even when you=20 have reserved bandwidth, but I can't think of any practical use. If your concern is purely that we should not second-guess what people might= =20 want in the future, you need not worry. Because if cc within a resv were=20 required, a simple extension to the e2e signalling protocol (RSVP or NSIS)= =20 would allow the endpoints to say they wanted to use ECN end-to-end. That=20 could be added if the need arose. But I don't see the need to add it now. " 4.3. Egress gateways Egress gateways do the following tasks: ---snip--- o Packet colouring - for CL packets, set the DSCP and the ECN field to whatever has been agreed as appropriate for the next domain. By default the ECN field is set to the Not-ECT codepoint. Note that this results in the loss of the end-to-end meaning of the ECN field. It can usually be assumed that end-to-end congestion control is unnecessary within an end-to-end reservation. But if a genuine need is identified for end-to-end ECN semantics within a reservation, then an alternative is to tunnel CL packets across the CL-region, or to agree an extension to end-to-end signalling to indicate that the microflow uses an ECN-capable transport. We do not recommend such apparently unnecessary complexity. " It's really a question of what everyone believes the default semantics of a= =20 reservation are today: a) end-to-end cc is not being used for reserved traffic? b) end-to-end cc is being used for reserved traffic? I believe, pragmatically, it is a). But perhaps you believe the current default position is (b)? If the=20 consensus of the TSVWG or NSIS w-gs is with you not me, we would have to=20 define extensions to RSVP and NSIS for the endpoints to flag that they were= =20 NOT intending to use end-to-end cc. To reduce complexity, I would want the= =20 default for the API to any new signalling stacks to be REQUIRED to be NO=20 end-to-end congestion control required. Then legacy hosts that want to use end-to-end cc would not need to signal=20 anything new. And if application writers using reservations said nothing and their=20 application was installed on an operating system compliant with the=20 signalling extension it would automatically signal that end-to-end cc was=20 not being used. App writers who wanted to use end-to-end cc within=20 reservations would have to explicitly call the API to say so. Cheers Bob >From: Attila B=E1der (IJ/ETH) > >To: "'Bob Briscoe'" >Cc: "Lars Westberg (KI/EAB)" , > karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'"= , > gqs@jungle.bt.co.uk >Subject: RE: RE: Meeting to discuss QoS >Date: Tue, 17 Aug 2004 08:33:01 +0200 >X-Mailer: Internet Mail Service (5.5.2657.72) >X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC)=20 >FILETIME=3D[0F6B35F0:01C48424] >X-MIME-Autoconverted: from quoted-printable to 8bit by=20 >bagheera.jungle.bt.co.uk id i7H6XA7S029034 > >Hi Bob, > >Thank you for your answers, I will think of them. [BB 10/11/05]: Haven't seen any response since --- until Georgios repeated= =20 the concern in the TSVWG mtg on Tuesday. >The work mentioned was not published, so I cannot send a ref. now. The=20 >contact person knows our investigation, even if not all the details,=20 >please let me know if you do not get answer from him. > >Best regards, Attila > > > -----Original Message----- > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > Sent: Thursday, August 12, 2004 1:54 PM > > To: Attila B=E1der (IJ/ETH) > > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; > > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk > > Subject: RE: RE: Meeting to discuss QoS > > > > > > Attila, > > > > Sorry for delay - been meeting a submission deadline. See below... > > > > At 15:58 06/08/04, IJ/ETH wrote: > > >Hi Bob, > > > > > >I apologize for the late answer, I was very busy during the > > summer and we > > >had to discuss your proposal. Yesterday we came together > > with Philip and > > >Lars for a discussion. > > > > > >We have the following main comments regarding the solutions sent us: > > > > > >We have also investigated similar solutions. > > > > [BB] Refs? > > > > >[AB] The main problem we see with ECN marking is that it has > > end-to-end scope. > > >The default behavior of ECN assumes that the end host switch > > on/off the > > >marking. > > > > [BB] We aren't using the default behaviour. I thought the paper makes= this > > clear. It says we're using all three of the RSVP, DSCP and > > ECN /protocols/, > > but none of their /architectures/, that is, we're not using > > the Intserv, > > Diffserv, or ECN-TCP architectures. We're just using ECN at > > the IP layer. > > The return path is an opaque object carried by the RSVP RESV > > from edge to > > edge. > > > > Traffic that has had a reservation signalled has ECT and a > > guaranteed DSCP > > turned on at the ingress gateway and turned off at the egress. > > > > Traffic not under a reservation (either not matching filterspec, or > > matching but overflowing the token bucket) is policed to > > ensure it isn't > > using the guaranteed DSCP. But ECT isn't touched, allowing > > the end systems > > to control how congestion is handled. > > > > We have various (unresolved) options if ECT is already on > > when reserved > > packets arrive. Obviously we leave it on at ingress, but the > > question is > > how to know not to turn it off at egress. Two possibilities: > > - extend the signalling to say what to do at egress (but this > > doesn't cope > > with some packets in the reservation having ECT on & others off). > > - tunnel between the gateways (wastes header space just to > > tunnel one bit) > > ---Snip loads of further conversation--- ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not=20 necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 11 10:11:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaaZ6-0002q1-6X; Fri, 11 Nov 2005 10:11:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKKS-0007US-HV for nsis@megatron.ietf.org; Thu, 10 Nov 2005 16:51:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18607 for ; Thu, 10 Nov 2005 16:51:03 -0500 (EST) Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaKak-0005YR-CW for nsis@ietf.org; Thu, 10 Nov 2005 17:08:23 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 21:51:17 +0000 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Nov 2005 21:51:17 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 21:51:16 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 113165947958; Thu, 10 Nov 2005 21:51:19 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.54]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id jAALoQDr002776; Thu, 10 Nov 2005 21:50:47 GMT Message-Id: <5.2.1.1.2.20051110210616.043e0d60@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 10 Nov 2005 21:44:25 +0000 To: , From: Bob Briscoe In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 10 Nov 2005 21:51:16.0790 (UTC) FILETIME=[E073AD60:01C5E640] X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 11 Nov 2005 10:11:42 -0500 Cc: Georgios Karagiannis , "Lars Westberg \(KI/EAB\)" , "Attila =?iso-8859-1?Q?B=E1der?= \(IJ/ETH\)" , philip.eardley@bt.com, "Anna Charny \(acharny\)" , Jozef Babiarz , Kwok-Ho Chan Subject: [NSIS] RE: RMD & pre-congestion notification: How edge-edge and end-end can interwork X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org TSVWG & NSIS, It's been pointed out that people on the list don't understand what my=20 original posting in this thread was about. I was replying to a point made=20 by Georgios at the mike in TSVWG without giving context. Context ------- It is about a difference in approach between RMD (in NSIS) and=20 pre-congestion notification (in TSVWG). Among other differences, this one=20 is about re-marking on routers within the Diffserv region if they are=20 congested. In both cases, this re-marked traffic is measured for the aggregate=20 arriving at the egress of the Diffserv region and if above a threshold,=20 admission of new flows to that aggregate is blocked. The difference is that routers in the interior of the region re-mark=20 differently: * RMD re-marks to another Diffserv codepoint and doesn't touch the ECN=20 field. * Pre-congestion notification re-marks to the CE codepoint of ECN=20 and doesn't touch the DSCP. One of the reasons RMD didn't touch the ECN codepoint was so as not to=20 interfere with end-to-end congestion control of the *same* flow. The pre-congestion notification approach deliberately chooses to re-mark=20 the ECN field, on the grounds that it is congestion that is being=20 signalled, albeit 'pre-congestion'. The draft says we think it very unlikely that anyone will be doing=20 end-to-end congestion control as well as reserving capacity for the same=20 flow. But, we say if anyone can give a good reason why this might happen,=20 we can add mechanism to allow both at once. But we don't want to add=20 complexity for what seems only a hypothetical requirement. So now, if you're interested, you can go back to the original posting and=20 perhaps understand the context. Sorry about that. Then, I'd be interested to hear from anyone who can argue for congestion=20 control within a reserved flow. Bob PS. As well as wire protocol differences, there are important semantic=20 differences in the meaning of a re-marked packet, but we'll we'll try to=20 reach consensus with the RMD authors on that off-line first then come back= =20 to the list with the conclusion. At 18:27 10/11/2005, IJ/ETH wrote: >Hi All, this link may work better, Attila > >http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-westberg-loadc= ntr-03.txt > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Thursday, November 10, 2005 6:46 PM > > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) > > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars Westberg > > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny); > > tsvwg@ietf.org; nsis@ietf.org > > Subject: Re: RMD & pre-congestion notification: How edge-edge and > > end-end can interwork > > > > > > > > Hi Bob > > > > Thank you for your e-mail! > > > > Please note that during an IETF meeting in 2000, Lars > > Westberg presented > > an Internet draft, see bellow, that used the ECN bits for edge2edge > > admission control purposes, but it could not become a WG draft. > > > > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt > > > > Best Regards, > > Georgios > > > > > > On 11/10/2005, "Bob Briscoe" wrote: > > > > >Attila, Georgios, > > > > > >[cross-posting tsvwg & nsis] > > > > > >Below is the mail I sent to you over a year ago solving your > > concerns over > > >interworking end-end & edge-edge ECN. > > > > > >The similar text below has been in > > > since the initial draft. > > > > > >As it says, if anyone can identify a genuine need to do e2e > > congestion > > >control within a reservation, we have a way to allow it. So > > if you have a > > >plausible reason for why anyone might ever want this, we are > > certainly > > >willing and able to accomodate you. But do you? > > > > > >We don't want to complicate the system if no-one will ever > > need it. I can > > >construct hypothetical scenarios where cc might be useful > > even when you > > >have reserved bandwidth, but I can't think of any practical use. > > > > > >If your concern is purely that we should not second-guess > > what people might > > >want in the future, you need not worry. Because if cc within > > a resv were > > >required, a simple extension to the e2e signalling protocol > > (RSVP or NSIS) > > >would allow the endpoints to say they wanted to use ECN > > end-to-end. That > > >could be added if the need arose. But I don't see the need > > to add it now. > > > > > >" > > >4.3. Egress gateways > > > > > > Egress gateways do the following tasks: > > > > > >---snip--- > > > > > > o Packet colouring - for CL packets, set the DSCP and > > the ECN field > > > to whatever has been agreed as appropriate for the > > next domain. By > > > default the ECN field is set to the Not-ECT > > codepoint. Note that > > > this results in the loss of the end-to-end meaning of the ECN > > > field. It can usually be assumed that end-to-end congestion > > > control is unnecessary within an end-to-end > > reservation. But if a > > > genuine need is identified for end-to-end ECN > > semantics within a > > > reservation, then an alternative is to tunnel CL > > packets across > > > the CL-region, or to agree an extension to end-to-end > > signalling > > > to indicate that the microflow uses an ECN-capable > > transport. We > > > do not recommend such apparently unnecessary complexity. > > > > > >" > > >It's really a question of what everyone believes the default > > semantics of a > > >reservation are today: > > >a) end-to-end cc is not being used for reserved traffic? > > >b) end-to-end cc is being used for reserved traffic? > > > > > >I believe, pragmatically, it is a). > > > > > >But perhaps you believe the current default position is (b)? If the > > >consensus of the TSVWG or NSIS w-gs is with you not me, we > > would have to > > >define extensions to RSVP and NSIS for the endpoints to flag > > that they were > > >NOT intending to use end-to-end cc. To reduce complexity, I > > would want the > > >default for the API to any new signalling stacks to be > > REQUIRED to be NO > > >end-to-end congestion control required. > > > > > >Then legacy hosts that want to use end-to-end cc would not > > need to signal > > >anything new. > > >And if application writers using reservations said nothing and their > > >application was installed on an operating system compliant with the > > >signalling extension it would automatically signal that > > end-to-end cc was > > >not being used. App writers who wanted to use end-to-end cc within > > >reservations would have to explicitly call the API to say so. > > > > > >Cheers > > > > > > > > > > > >Bob > > > > > >>From: Attila B=E1der (IJ/ETH) > > >> > > >>To: "'Bob Briscoe'" > > >>Cc: "Lars Westberg (KI/EAB)" , > > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" > > , > > >> gqs@jungle.bt.co.uk > > >>Subject: RE: RE: Meeting to discuss QoS > > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 > > >>X-Mailer: Internet Mail Service (5.5.2657.72) > > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC) > > >>FILETIME=3D[0F6B35F0:01C48424] > > >>X-MIME-Autoconverted: from quoted-printable to 8bit by > > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 > > >> > > >>Hi Bob, > > >> > > >>Thank you for your answers, I will think of them. > > > > > >[BB 10/11/05]: Haven't seen any response since --- until > > Georgios repeated > > >the concern in the TSVWG mtg on Tuesday. > > > > > >>The work mentioned was not published, so I cannot send a > > ref. now. The > > >>contact person knows our investigation, even if not all the details, > > >>please let me know if you do not get answer from him. > > >> > > >>Best regards, Attila > > >> > > >> > -----Original Message----- > > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > >> > Sent: Thursday, August 12, 2004 1:54 PM > > >> > To: Attila B=E1der (IJ/ETH) > > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; > > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk > > >> > Subject: RE: RE: Meeting to discuss QoS > > >> > > > >> > > > >> > Attila, > > >> > > > >> > Sorry for delay - been meeting a submission deadline. > > See below... > > >> > > > >> > At 15:58 06/08/04, IJ/ETH wrote: > > >> > >Hi Bob, > > >> > > > > >> > >I apologize for the late answer, I was very busy during the > > >> > summer and we > > >> > >had to discuss your proposal. Yesterday we came together > > >> > with Philip and > > >> > >Lars for a discussion. > > >> > > > > >> > >We have the following main comments regarding the > > solutions sent us: > > >> > > > > >> > >We have also investigated similar solutions. > > >> > > > >> > [BB] Refs? > > >> > > > >> > >[AB] The main problem we see with ECN marking is that it has > > >> > end-to-end scope. > > >> > >The default behavior of ECN assumes that the end host switch > > >> > on/off the > > >> > >marking. > > >> > > > >> > [BB] We aren't using the default behaviour. I thought > > the paper makes this > > >> > clear. It says we're using all three of the RSVP, DSCP and > > >> > ECN /protocols/, > > >> > but none of their /architectures/, that is, we're not using > > >> > the Intserv, > > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at > > >> > the IP layer. > > >> > The return path is an opaque object carried by the RSVP RESV > > >> > from edge to > > >> > edge. > > >> > > > >> > Traffic that has had a reservation signalled has ECT and a > > >> > guaranteed DSCP > > >> > turned on at the ingress gateway and turned off at the egress. > > >> > > > >> > Traffic not under a reservation (either not matching > > filterspec, or > > >> > matching but overflowing the token bucket) is policed to > > >> > ensure it isn't > > >> > using the guaranteed DSCP. But ECT isn't touched, allowing > > >> > the end systems > > >> > to control how congestion is handled. > > >> > > > >> > We have various (unresolved) options if ECT is already on > > >> > when reserved > > >> > packets arrive. Obviously we leave it on at ingress, but the > > >> > question is > > >> > how to know not to turn it off at egress. Two possibilities: > > >> > - extend the signalling to say what to do at egress (but this > > >> > doesn't cope > > >> > with some packets in the reservation having ECT on & others off). > > >> > - tunnel between the gateways (wastes header space just to > > >> > tunnel one bit) > > >> > > > > > > >---Snip loads of further conversation--- > > > > > > > > > > > >_____________________________________________________________ > > _______________ > > >Notice: This contribution is the personal view of the author > > and does not > > >necessarily reflect the technical nor commercial direction of BT plc. > > >_____________________________________________________________ > > _______________ > > >Bob Briscoe, Networks Research > > Centre, BT Research > > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > > +44 1473 645196 > > > > > > > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 11 13:31:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EadgM-0007G0-G5; Fri, 11 Nov 2005 13:31:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EadgK-0007Fo-Kn for nsis@megatron.ietf.org; Fri, 11 Nov 2005 13:31:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25924 for ; Fri, 11 Nov 2005 13:30:54 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eadwn-0008HW-ML for nsis@ietf.org; Fri, 11 Nov 2005 13:48:26 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jABISaZt010989 for ; Fri, 11 Nov 2005 20:28:38 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 20:31:22 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 20:31:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Nov 2005 20:31:20 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D015CB752@esebe100.NOE.Nokia.com> Thread-Topic: Presentation from the meeting Thread-Index: AcXm7hwjxwJoWmvQT/22pL//0mwJhw== To: X-OriginalArrivalTime: 11 Nov 2005 18:31:23.0002 (UTC) FILETIME=[1E029DA0:01C5E6EE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Presentation from the meeting X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, I have posted the presentations from IETF 64.=20 https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=3D64 I'm currently missing presentations from Jerry Ash, Charles Shen/Henning, Andreas Pashalidis=20 (at least). Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 14 03:55:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eba81-0003tM-T0; Mon, 14 Nov 2005 03:55:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eba80-0003tD-94 for nsis@megatron.ietf.org; Mon, 14 Nov 2005 03:55:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06365 for ; Mon, 14 Nov 2005 03:55:19 -0500 (EST) Received: from [202.54.26.114] (helo=ipc-smtp.bits-pilani.ac.in) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EbaOx-0004FA-EG for nsis@ietf.org; Mon, 14 Nov 2005 04:13:25 -0500 Received: from bitshub01.bits-pilani.ac.in ([172.24.2.81]) by ipc-smtp.bits-pilani.ac.in (SAVSMTP 3.1.0.29) with SMTP id M2005111414191507291 for ; Mon, 14 Nov 2005 14:19:15 +0530 Received: from AK233 ([172.16.2.47]) by bitsmail01.bits-pilani.ac.in (Lotus Domino Release 6.5.3) with ESMTP id 2005111413234033-2462 ; Mon, 14 Nov 2005 13:23:40 -0800 From: "Amit Vyas" To: Date: Mon, 14 Nov 2005 14:27:01 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcXo+VtUm6TE33VsS6Cg+adOyA1Ywg== X-MIMETrack: Itemize by SMTP Server on BitsMail01/Bits(Release 6.5.3|September 14, 2004) at 11/14/2005 01:23:41 PM, Serialize by Router on BitsHub01/Bits(Release 6.5.3|September 14, 2004) at 11/14/2005 02:22:38 PM, Serialize complete at 11/14/2005 02:22:38 PM Message-ID: X-Spam-Score: 0.9 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [NSIS] Query for QoS signaling testbed setup X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: amitvyas.cse@gmail.com List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1125290640==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1125290640== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C5E927.7D1A2930" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C5E927.7D1A2930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, This may sound out of context sorry for that, I would like to setup a testbed for QoS signaling. Could anybody provide me information on how to go about such an implementation specifically in configuration of various network components routers and selection of protocols? Thanks Amit Vyas ------=_NextPart_000_0010_01C5E927.7D1A2930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

This may sound out of context sorry for that, I would = like to setup a testbed for QoS signaling. Could anybody provide me information = on how to go about such an implementation specifically in configuration of various = network components routers and selection of protocols? =

 

Thanks

Amit Vyas

 

------=_NextPart_000_0010_01C5E927.7D1A2930-- --===============1125290640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1125290640==-- From nsis-bounces@ietf.org Mon Nov 14 06:14:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbcI2-0000B8-M3; Mon, 14 Nov 2005 06:14:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbcI0-0000Az-TJ; Mon, 14 Nov 2005 06:14:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12583; Mon, 14 Nov 2005 06:13:50 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbcZ0-0008Bl-Tw; Mon, 14 Nov 2005 06:31:56 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAEBEEAu019634; Mon, 14 Nov 2005 13:14:15 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 13:14:14 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 13:14:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2005 13:14:12 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D015CB93F@esebe100.NOE.Nokia.com> Thread-Topic: [Tsvwg] RMD & pre-congestion notification: How edge-edge and end-end can interwork Thread-Index: AcXonGyYQz0FezodQV2PNpZNjPNKkwAb2x5w To: , , X-OriginalArrivalTime: 14 Nov 2005 11:14:14.0444 (UTC) FILETIME=[8BCF86C0:01C5E90C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: babiarz@nortel.com, philip.eardley@bt.com, lars.westberg@ericsson.com, tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] RE: [Tsvwg] RMD & pre-congestion notification: How edge-edge and end-end can interwork X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Bob, Just jumping in the middle of the discussion: >As it says, if anyone can identify a genuine need to do e2e=20 >congestion control within a reservation, we have a way to=20 >allow it. So if you have a plausible reason for why anyone=20 >might ever want this, we are certainly willing and able to=20 >accomodate you. But do you? The NSIS work, as you know, is supporting end-to-end signaling (as well as end-to-middle signaling, etc.). From my discussions with the RMD authors, the feeling is that in some networks (especially mobile / cellular networks) there might need to be additional protection for severe conditions that could cause failure in certain parts of the network due to link failure, etc. My guess is this wouldn't be in the middle of the network, but certain links in access networks. =20 I'm sure that Attila or Georgios could sketch out a better scenario for this, but I think for certain deployments, this makes sense. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 14 08:25:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbeKo-00081C-K6; Mon, 14 Nov 2005 08:25:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbeBu-0006mX-Ji; Mon, 14 Nov 2005 08:16:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19917; Mon, 14 Nov 2005 08:15:39 -0500 (EST) Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbeSv-0003l2-PQ; Mon, 14 Nov 2005 08:33:47 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Mon, 14 Nov 2005 14:15:49 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Nov 2005 14:15:49 +0100 Message-Id: <5F9130612D07074EB0A0CE7E69FD7A0306430A4A@S4DE8PSAAGS.blf.telekom.de> From: "Geib, Ruediger" To: rbriscoe@jungle.bt.co.uk Subject: RE: [NSIS] RE: RMD & pre-congestion notification: How edge-edge a nd end-end can interwork Date: Mon, 14 Nov 2005 14:15:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Nov 2005 08:25:22 -0500 Cc: karagian@cs.utwente.nl, lars.westberg@ericsson.com, tsvwg@ietf.org, nsis@ietf.org, attila.bader@ericsson.com, philip.eardley@bt.com, khchan@nortel.com, babiarz@nortel.com, acharny@cisco.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Bob, |The pre-congestion notification approach deliberately chooses=20 |to re-mark the ECN field, on the grounds that it is congestion=20 |that is being signalled, albeit 'pre-congestion'. | |The draft says we think it very unlikely that anyone will be doing=20 |end-to-end congestion control as well as reserving capacity=20 |for the same flow. But, we say if anyone can give a good reason=20 |why this might happen,=20 |we can add mechanism to allow both at once. But we don't want to add=20 |complexity for what seems only a hypothetical requirement. I didn't read your draft completely. I like your approach. I'll comment = as soon as I have time to go into details. I think your teams idea should be supported by MPLS domains and NSIS = should=20 be accepted as an alternative to RSVP. Further, input in the SIP area = may be=20 required (preconditions/RFC3312 and follow up - but I may be wrong = here,=20 as I didn't read your draft careful enough). Good work! Regards,=20 R=FCdiger R=FCdiger Geib T-Systems International GmbH Senior Expert Systems Integration=20 Technologiezentrum Engineering Networks, Products & Services Packet based Carrier Transport Networks Deutsche-Telekom-Allee 7, D-64295 Darmstadt Fon: +49 6151 937-2138 http://www.t-systems.com =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 14 12:24:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebi4F-0008WU-FC; Mon, 14 Nov 2005 12:24:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebi4E-0008Vy-AP; Mon, 14 Nov 2005 12:24:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06629; Mon, 14 Nov 2005 12:23:59 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbiLB-000465-7z; Mon, 14 Nov 2005 12:42:08 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C38804EF; Mon, 14 Nov 2005 18:24:13 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 18:24:13 +0100 Content-class: urn:content-classes:message Subject: RE: [NSIS] RE: RMD & pre-congestion notification: How edge-edge and end-end can interwork MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2005 18:24:11 +0100 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [NSIS] RE: RMD & pre-congestion notification: How edge-edge and end-end can interwork Thread-Index: AcXm0rQtuST9QAEWQSuTIY3XyO6JdQCanEaA From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Bob Briscoe" , , X-OriginalArrivalTime: 14 Nov 2005 17:24:13.0508 (UTC) FILETIME=[3B7BE040:01C5E940] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: quoted-printable Cc: Georgios Karagiannis , "Lars Westberg \(KI/EAB\)" , philip.eardley@bt.com, "Anna Charny \(acharny\)" , Jozef Babiarz , Kwok-Ho Chan X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Bob, I would not say that ECN marking for rt-traffic will not work (et least = edge-to-edge). I am wondering what people think of it. In RMD we use = DSCP re-marking that do not have conflict with previous definitions.=20 Best regards, Attila > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] > Sent: Thursday, November 10, 2005 10:44 PM > To: tsvwg@ietf.org; nsis@ietf.org > Cc: Georgios Karagiannis; Lars Westberg (KI/EAB); Attila=20 > B=E1der (IJ/ETH); > philip.eardley@bt.com; Anna Charny (acharny); Jozef Babiarz; Kwok-Ho > Chan > Subject: [NSIS] RE: RMD & pre-congestion notification: How=20 > edge-edge and > end-end can interwork >=20 >=20 > TSVWG & NSIS, >=20 > It's been pointed out that people on the list don't=20 > understand what my=20 > original posting in this thread was about. I was replying to=20 > a point made=20 > by Georgios at the mike in TSVWG without giving context. >=20 > Context > ------- > It is about a difference in approach between RMD (in NSIS) and=20 > pre-congestion notification (in TSVWG). Among other=20 > differences, this one=20 > is about re-marking on routers within the Diffserv region if they are=20 > congested. >=20 > In both cases, this re-marked traffic is measured for the aggregate=20 > arriving at the egress of the Diffserv region and if above a=20 > threshold,=20 > admission of new flows to that aggregate is blocked. >=20 > The difference is that routers in the interior of the region re-mark=20 > differently: > * RMD re-marks to another Diffserv codepoint and doesn't=20 > touch the ECN=20 > field. * Pre-congestion notification re-marks to the CE=20 > codepoint of ECN=20 > and doesn't touch the DSCP. >=20 > One of the reasons RMD didn't touch the ECN codepoint was so=20 > as not to=20 > interfere with end-to-end congestion control of the *same* flow. >=20 > The pre-congestion notification approach deliberately chooses=20 > to re-mark=20 > the ECN field, on the grounds that it is congestion that is being=20 > signalled, albeit 'pre-congestion'. >=20 > The draft says we think it very unlikely that anyone will be doing=20 > end-to-end congestion control as well as reserving capacity=20 > for the same=20 > flow. But, we say if anyone can give a good reason why this=20 > might happen,=20 > we can add mechanism to allow both at once. But we don't want to add=20 > complexity for what seems only a hypothetical requirement. >=20 > So now, if you're interested, you can go back to the original=20 > posting and=20 > perhaps understand the context. >=20 > Sorry about that. >=20 > Then, I'd be interested to hear from anyone who can argue for=20 > congestion=20 > control within a reserved flow. >=20 >=20 >=20 >=20 > Bob >=20 > PS. As well as wire protocol differences, there are important=20 > semantic=20 > differences in the meaning of a re-marked packet, but we'll=20 > we'll try to=20 > reach consensus with the RMD authors on that off-line first=20 > then come back=20 > to the list with the conclusion. >=20 >=20 >=20 > At 18:27 10/11/2005, IJ/ETH wrote: > >Hi All, this link may work better, Attila > > > >http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft- > westberg-loadcntr-03.txt > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Thursday, November 10, 2005 6:46 PM > > > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) > > > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com;=20 > Lars Westberg > > > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny); > > > tsvwg@ietf.org; nsis@ietf.org > > > Subject: Re: RMD & pre-congestion notification: How edge-edge and > > > end-end can interwork > > > > > > > > > > > > Hi Bob > > > > > > Thank you for your e-mail! > > > > > > Please note that during an IETF meeting in 2000, Lars > > > Westberg presented > > > an Internet draft, see bellow, that used the ECN bits for=20 > edge2edge > > > admission control purposes, but it could not become a WG draft. > > > > > > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt > > > > > > Best Regards, > > > Georgios > > > > > > > > > On 11/10/2005, "Bob Briscoe" wrote: > > > > > > >Attila, Georgios, > > > > > > > >[cross-posting tsvwg & nsis] > > > > > > > >Below is the mail I sent to you over a year ago solving your > > > concerns over > > > >interworking end-end & edge-edge ECN. > > > > > > > >The similar text below has been in > > > > since the=20 > initial draft. > > > > > > > >As it says, if anyone can identify a genuine need to do e2e > > > congestion > > > >control within a reservation, we have a way to allow it. So > > > if you have a > > > >plausible reason for why anyone might ever want this, we are > > > certainly > > > >willing and able to accomodate you. But do you? > > > > > > > >We don't want to complicate the system if no-one will ever > > > need it. I can > > > >construct hypothetical scenarios where cc might be useful > > > even when you > > > >have reserved bandwidth, but I can't think of any practical use. > > > > > > > >If your concern is purely that we should not second-guess > > > what people might > > > >want in the future, you need not worry. Because if cc within > > > a resv were > > > >required, a simple extension to the e2e signalling protocol > > > (RSVP or NSIS) > > > >would allow the endpoints to say they wanted to use ECN > > > end-to-end. That > > > >could be added if the need arose. But I don't see the need > > > to add it now. > > > > > > > >" > > > >4.3. Egress gateways > > > > > > > > Egress gateways do the following tasks: > > > > > > > >---snip--- > > > > > > > > o Packet colouring - for CL packets, set the DSCP and > > > the ECN field > > > > to whatever has been agreed as appropriate for the > > > next domain. By > > > > default the ECN field is set to the Not-ECT > > > codepoint. Note that > > > > this results in the loss of the end-to-end=20 > meaning of the ECN > > > > field. It can usually be assumed that end-to-end=20 > congestion > > > > control is unnecessary within an end-to-end > > > reservation. But if a > > > > genuine need is identified for end-to-end ECN > > > semantics within a > > > > reservation, then an alternative is to tunnel CL > > > packets across > > > > the CL-region, or to agree an extension to end-to-end > > > signalling > > > > to indicate that the microflow uses an ECN-capable > > > transport. We > > > > do not recommend such apparently unnecessary complexity. > > > > > > > >" > > > >It's really a question of what everyone believes the default > > > semantics of a > > > >reservation are today: > > > >a) end-to-end cc is not being used for reserved traffic? > > > >b) end-to-end cc is being used for reserved traffic? > > > > > > > >I believe, pragmatically, it is a). > > > > > > > >But perhaps you believe the current default position is=20 > (b)? If the > > > >consensus of the TSVWG or NSIS w-gs is with you not me, we > > > would have to > > > >define extensions to RSVP and NSIS for the endpoints to flag > > > that they were > > > >NOT intending to use end-to-end cc. To reduce complexity, I > > > would want the > > > >default for the API to any new signalling stacks to be > > > REQUIRED to be NO > > > >end-to-end congestion control required. > > > > > > > >Then legacy hosts that want to use end-to-end cc would not > > > need to signal > > > >anything new. > > > >And if application writers using reservations said=20 > nothing and their > > > >application was installed on an operating system=20 > compliant with the > > > >signalling extension it would automatically signal that > > > end-to-end cc was > > > >not being used. App writers who wanted to use end-to-end=20 > cc within > > > >reservations would have to explicitly call the API to say so. > > > > > > > >Cheers > > > > > > > > > > > > > > > >Bob > > > > > > > >>From: Attila B=E1der (IJ/ETH) > > > >> > > > >>To: "'Bob Briscoe'" > > > >>Cc: "Lars Westberg (KI/EAB)" , > > > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" > > > , > > > >> gqs@jungle.bt.co.uk > > > >>Subject: RE: RE: Meeting to discuss QoS > > > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 > > > >>X-Mailer: Internet Mail Service (5.5.2657.72) > > > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC) > > > >>FILETIME=3D[0F6B35F0:01C48424] > > > >>X-MIME-Autoconverted: from quoted-printable to 8bit by > > > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 > > > >> > > > >>Hi Bob, > > > >> > > > >>Thank you for your answers, I will think of them. > > > > > > > >[BB 10/11/05]: Haven't seen any response since --- until > > > Georgios repeated > > > >the concern in the TSVWG mtg on Tuesday. > > > > > > > >>The work mentioned was not published, so I cannot send a > > > ref. now. The > > > >>contact person knows our investigation, even if not all=20 > the details, > > > >>please let me know if you do not get answer from him. > > > >> > > > >>Best regards, Attila > > > >> > > > >> > -----Original Message----- > > > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > > >> > Sent: Thursday, August 12, 2004 1:54 PM > > > >> > To: Attila B=E1der (IJ/ETH) > > > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; > > > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk > > > >> > Subject: RE: RE: Meeting to discuss QoS > > > >> > > > > >> > > > > >> > Attila, > > > >> > > > > >> > Sorry for delay - been meeting a submission deadline. > > > See below... > > > >> > > > > >> > At 15:58 06/08/04, IJ/ETH wrote: > > > >> > >Hi Bob, > > > >> > > > > > >> > >I apologize for the late answer, I was very busy during the > > > >> > summer and we > > > >> > >had to discuss your proposal. Yesterday we came together > > > >> > with Philip and > > > >> > >Lars for a discussion. > > > >> > > > > > >> > >We have the following main comments regarding the > > > solutions sent us: > > > >> > > > > > >> > >We have also investigated similar solutions. > > > >> > > > > >> > [BB] Refs? > > > >> > > > > >> > >[AB] The main problem we see with ECN marking is that it has > > > >> > end-to-end scope. > > > >> > >The default behavior of ECN assumes that the end host switch > > > >> > on/off the > > > >> > >marking. > > > >> > > > > >> > [BB] We aren't using the default behaviour. I thought > > > the paper makes this > > > >> > clear. It says we're using all three of the RSVP, DSCP and > > > >> > ECN /protocols/, > > > >> > but none of their /architectures/, that is, we're not using > > > >> > the Intserv, > > > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at > > > >> > the IP layer. > > > >> > The return path is an opaque object carried by the RSVP RESV > > > >> > from edge to > > > >> > edge. > > > >> > > > > >> > Traffic that has had a reservation signalled has ECT and a > > > >> > guaranteed DSCP > > > >> > turned on at the ingress gateway and turned off at=20 > the egress. > > > >> > > > > >> > Traffic not under a reservation (either not matching > > > filterspec, or > > > >> > matching but overflowing the token bucket) is policed to > > > >> > ensure it isn't > > > >> > using the guaranteed DSCP. But ECT isn't touched, allowing > > > >> > the end systems > > > >> > to control how congestion is handled. > > > >> > > > > >> > We have various (unresolved) options if ECT is already on > > > >> > when reserved > > > >> > packets arrive. Obviously we leave it on at ingress, but the > > > >> > question is > > > >> > how to know not to turn it off at egress. Two possibilities: > > > >> > - extend the signalling to say what to do at egress (but this > > > >> > doesn't cope > > > >> > with some packets in the reservation having ECT on &=20 > others off). > > > >> > - tunnel between the gateways (wastes header space just to > > > >> > tunnel one bit) > > > >> > > > > > > > > >---Snip loads of further conversation--- > > > > > > > > > > > > > > > >_____________________________________________________________ > > > _______________ > > > >Notice: This contribution is the personal view of the author > > > and does not > > > >necessarily reflect the technical nor commercial=20 > direction of BT plc. > > > >_____________________________________________________________ > > > _______________ > > > >Bob Briscoe, Networks Research > > > Centre, BT Research > > > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > > > +44 1473 645196 > > > > > > > > > > > >=20 > ______________________________________________________________ > ______________ > Bob Briscoe, Networks Research=20 > Centre, BT Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. =20 > +44 1473 645196=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Nov 15 15:37:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7Yf-00070e-AM; Tue, 15 Nov 2005 15:37:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7Yc-000701-VH; Tue, 15 Nov 2005 15:37:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24564; Tue, 15 Nov 2005 15:37:02 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7oH-0002SL-4O; Tue, 15 Nov 2005 15:55:28 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id jAFKZaRd018082; Tue, 15 Nov 2005 21:35:36 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id jAFKZ05B017338; Tue, 15 Nov 2005 21:35:35 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id jAFKYrg19168; Tue, 15 Nov 2005 21:34:53 +0100 (MET) Date: Tue, 15 Nov 2005 21:34:53 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: rbriscoe@jungle.bt.co.uk, tsvwg@ietf.org, nsis@ietf.org Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 15 Nov 2005 20:34:53 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <5.2.1.1.2.20051110210616.043e0d60@pop3.jungle.bt.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.205 () ALL_TRUSTED, AWL, BAYES_00, FVGT_u_HAS_2LETTERFLDR, J_CHICKENPOX_57, MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 15 Nov 2005 21:35:41 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Content-Transfer-Encoding: quoted-printable Cc: Subject: [NSIS] interoperability problems between end-to-end ECN and edge-to-edge ECN X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Bob Yes I agree, the admission control based on (pre-)congestion notification and the severe congestion (or pre-emption) used in RMD and in your proposal are very similar. The main difference of your proposal compared to RMD is that the ECN re-marking is used instead of DSCP re-marking. During the tsvwg meeting, I have tried to emphasize that ECN is designed to be an end-to-end concept and not an edge-to-edge concept. When ECN is used for edge-to-edge purposes this might limit the current and future applicability of the (end-to-end) ECN concept. For example, the current and future applicability of the DCCP protocol might be restricted since streaming applications might not be able to use the complete semantics of the end-to-end ECN concept. This problem can become more severe if streaming applications will be using DCCP in combination with a QoS reservation (or a Diffserv based QoS support). Note that this reservation might not go end-to-end, but for example end-to-edge. Best Regards, Georgios On 11/10/2005, "Bob Briscoe" wrote: >TSVWG & NSIS, > >It's been pointed out that people on the list don't understand what my >original posting in this thread was about. I was replying to a point made >by Georgios at the mike in TSVWG without giving context. > >Context >------- >It is about a difference in approach between RMD (in NSIS) and >pre-congestion notification (in TSVWG). Among other differences, this one >is about re-marking on routers within the Diffserv region if they are >congested. > >In both cases, this re-marked traffic is measured for the aggregate >arriving at the egress of the Diffserv region and if above a threshold, >admission of new flows to that aggregate is blocked. > >The difference is that routers in the interior of the region re-mark >differently: >* RMD re-marks to another Diffserv codepoint and doesn't touch the ECN >field. * Pre-congestion notification re-marks to the CE codepoint of ECN >and doesn't touch the DSCP. > >One of the reasons RMD didn't touch the ECN codepoint was so as not to >interfere with end-to-end congestion control of the *same* flow. > >The pre-congestion notification approach deliberately chooses to re-mark >the ECN field, on the grounds that it is congestion that is being >signalled, albeit 'pre-congestion'. > >The draft says we think it very unlikely that anyone will be doing >end-to-end congestion control as well as reserving capacity for the same >flow. But, we say if anyone can give a good reason why this might happen, >we can add mechanism to allow both at once. But we don't want to add >complexity for what seems only a hypothetical requirement. > >So now, if you're interested, you can go back to the original posting and >perhaps understand the context. > >Sorry about that. > >Then, I'd be interested to hear from anyone who can argue for congestion >control within a reserved flow. > > > > >Bob > >PS. As well as wire protocol differences, there are important semantic >differences in the meaning of a re-marked packet, but we'll we'll try to >reach consensus with the RMD authors on that off-line first then come back >to the list with the conclusion. > > > >At 18:27 10/11/2005, IJ/ETH wrote: >>Hi All, this link may work better, Attila >> >>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-westberg-loadc= ntr-03.txt >> >> > -----Original Message----- >> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> > Sent: Thursday, November 10, 2005 6:46 PM >> > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) >> > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars Westberg >> > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny); >> > tsvwg@ietf.org; nsis@ietf.org >> > Subject: Re: RMD & pre-congestion notification: How edge-edge and >> > end-end can interwork >> > >> > >> > >> > Hi Bob >> > >> > Thank you for your e-mail! >> > >> > Please note that during an IETF meeting in 2000, Lars >> > Westberg presented >> > an Internet draft, see bellow, that used the ECN bits for edge2edge >> > admission control purposes, but it could not become a WG draft. >> > >> > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt >> > >> > Best Regards, >> > Georgios >> > >> > >> > On 11/10/2005, "Bob Briscoe" wrote: >> > >> > >Attila, Georgios, >> > > >> > >[cross-posting tsvwg & nsis] >> > > >> > >Below is the mail I sent to you over a year ago solving your >> > concerns over >> > >interworking end-end & edge-edge ECN. >> > > >> > >The similar text below has been in >> > > since the initial draft. >> > > >> > >As it says, if anyone can identify a genuine need to do e2e >> > congestion >> > >control within a reservation, we have a way to allow it. So >> > if you have a >> > >plausible reason for why anyone might ever want this, we are >> > certainly >> > >willing and able to accomodate you. But do you? >> > > >> > >We don't want to complicate the system if no-one will ever >> > need it. I can >> > >construct hypothetical scenarios where cc might be useful >> > even when you >> > >have reserved bandwidth, but I can't think of any practical use. >> > > >> > >If your concern is purely that we should not second-guess >> > what people might >> > >want in the future, you need not worry. Because if cc within >> > a resv were >> > >required, a simple extension to the e2e signalling protocol >> > (RSVP or NSIS) >> > >would allow the endpoints to say they wanted to use ECN >> > end-to-end. That >> > >could be added if the need arose. But I don't see the need >> > to add it now. >> > > >> > >" >> > >4.3. Egress gateways >> > > >> > > Egress gateways do the following tasks: >> > > >> > >---snip--- >> > > >> > > o Packet colouring - for CL packets, set the DSCP and >> > the ECN field >> > > to whatever has been agreed as appropriate for the >> > next domain. By >> > > default the ECN field is set to the Not-ECT >> > codepoint. Note that >> > > this results in the loss of the end-to-end meaning of the ECN >> > > field. It can usually be assumed that end-to-end congestion >> > > control is unnecessary within an end-to-end >> > reservation. But if a >> > > genuine need is identified for end-to-end ECN >> > semantics within a >> > > reservation, then an alternative is to tunnel CL >> > packets across >> > > the CL-region, or to agree an extension to end-to-end >> > signalling >> > > to indicate that the microflow uses an ECN-capable >> > transport. We >> > > do not recommend such apparently unnecessary complexity. >> > > >> > >" >> > >It's really a question of what everyone believes the default >> > semantics of a >> > >reservation are today: >> > >a) end-to-end cc is not being used for reserved traffic? >> > >b) end-to-end cc is being used for reserved traffic? >> > > >> > >I believe, pragmatically, it is a). >> > > >> > >But perhaps you believe the current default position is (b)? If the >> > >consensus of the TSVWG or NSIS w-gs is with you not me, we >> > would have to >> > >define extensions to RSVP and NSIS for the endpoints to flag >> > that they were >> > >NOT intending to use end-to-end cc. To reduce complexity, I >> > would want the >> > >default for the API to any new signalling stacks to be >> > REQUIRED to be NO >> > >end-to-end congestion control required. >> > > >> > >Then legacy hosts that want to use end-to-end cc would not >> > need to signal >> > >anything new. >> > >And if application writers using reservations said nothing and their >> > >application was installed on an operating system compliant with the >> > >signalling extension it would automatically signal that >> > end-to-end cc was >> > >not being used. App writers who wanted to use end-to-end cc within >> > >reservations would have to explicitly call the API to say so. >> > > >> > >Cheers >> > > >> > > >> > > >> > >Bob >> > > >> > >>From: Attila B=E1der (IJ/ETH) >> > >> >> > >>To: "'Bob Briscoe'" >> > >>Cc: "Lars Westberg (KI/EAB)" , >> > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" >> > , >> > >> gqs@jungle.bt.co.uk >> > >>Subject: RE: RE: Meeting to discuss QoS >> > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 >> > >>X-Mailer: Internet Mail Service (5.5.2657.72) >> > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC) >> > >>FILETIME=3D[0F6B35F0:01C48424] >> > >>X-MIME-Autoconverted: from quoted-printable to 8bit by >> > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 >> > >> >> > >>Hi Bob, >> > >> >> > >>Thank you for your answers, I will think of them. >> > > >> > >[BB 10/11/05]: Haven't seen any response since --- until >> > Georgios repeated >> > >the concern in the TSVWG mtg on Tuesday. >> > > >> > >>The work mentioned was not published, so I cannot send a >> > ref. now. The >> > >>contact person knows our investigation, even if not all the details, >> > >>please let me know if you do not get answer from him. >> > >> >> > >>Best regards, Attila >> > >> >> > >> > -----Original Message----- >> > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >> > >> > Sent: Thursday, August 12, 2004 1:54 PM >> > >> > To: Attila B=E1der (IJ/ETH) >> > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; >> > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk >> > >> > Subject: RE: RE: Meeting to discuss QoS >> > >> > >> > >> > >> > >> > Attila, >> > >> > >> > >> > Sorry for delay - been meeting a submission deadline. >> > See below... >> > >> > >> > >> > At 15:58 06/08/04, IJ/ETH wrote: >> > >> > >Hi Bob, >> > >> > > >> > >> > >I apologize for the late answer, I was very busy during the >> > >> > summer and we >> > >> > >had to discuss your proposal. Yesterday we came together >> > >> > with Philip and >> > >> > >Lars for a discussion. >> > >> > > >> > >> > >We have the following main comments regarding the >> > solutions sent us: >> > >> > > >> > >> > >We have also investigated similar solutions. >> > >> > >> > >> > [BB] Refs? >> > >> > >> > >> > >[AB] The main problem we see with ECN marking is that it has >> > >> > end-to-end scope. >> > >> > >The default behavior of ECN assumes that the end host switch >> > >> > on/off the >> > >> > >marking. >> > >> > >> > >> > [BB] We aren't using the default behaviour. I thought >> > the paper makes this >> > >> > clear. It says we're using all three of the RSVP, DSCP and >> > >> > ECN /protocols/, >> > >> > but none of their /architectures/, that is, we're not using >> > >> > the Intserv, >> > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at >> > >> > the IP layer. >> > >> > The return path is an opaque object carried by the RSVP RESV >> > >> > from edge to >> > >> > edge. >> > >> > >> > >> > Traffic that has had a reservation signalled has ECT and a >> > >> > guaranteed DSCP >> > >> > turned on at the ingress gateway and turned off at the egress. >> > >> > >> > >> > Traffic not under a reservation (either not matching >> > filterspec, or >> > >> > matching but overflowing the token bucket) is policed to >> > >> > ensure it isn't >> > >> > using the guaranteed DSCP. But ECT isn't touched, allowing >> > >> > the end systems >> > >> > to control how congestion is handled. >> > >> > >> > >> > We have various (unresolved) options if ECT is already on >> > >> > when reserved >> > >> > packets arrive. Obviously we leave it on at ingress, but the >> > >> > question is >> > >> > how to know not to turn it off at egress. Two possibilities: >> > >> > - extend the signalling to say what to do at egress (but this >> > >> > doesn't cope >> > >> > with some packets in the reservation having ECT on & others off). >> > >> > - tunnel between the gateways (wastes header space just to >> > >> > tunnel one bit) >> > >> > >> > > >> > >---Snip loads of further conversation--- >> > > >> > > >> > > >> > >_____________________________________________________________ >> > _______________ >> > >Notice: This contribution is the personal view of the author >> > and does not >> > >necessarily reflect the technical nor commercial direction of BT plc. >> > >_____________________________________________________________ >> > _______________ >> > >Bob Briscoe, Networks Research >> > Centre, BT Research >> > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >> > +44 1473 645196 >> > > >> > > >> > > >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 16 04:58:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK3r-0003yb-FC; Wed, 16 Nov 2005 04:58:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcK3p-0003y2-EY; Wed, 16 Nov 2005 04:58:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13905; Wed, 16 Nov 2005 04:58:04 -0500 (EST) From: philip.eardley@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcKLE-000276-K2; Wed, 16 Nov 2005 05:16:37 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 09:58:26 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 09:58:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] interoperability problems between end-to-end ECN andedge-to-edge ECN Date: Wed, 16 Nov 2005 09:58:19 -0000 Message-ID: Thread-Topic: [NSIS] interoperability problems between end-to-end ECN andedge-to-edge ECN Thread-Index: AcXqJJpQkWqST+0OTcaiqr+C27UJuQAb1d1g To: , , , X-OriginalArrivalTime: 16 Nov 2005 09:58:20.0397 (UTC) FILETIME=[463699D0:01C5EA94] X-Spam-Score: 0.3 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios Please can you explain the scenario a bit more. I don't understand it = yet [I think you have a dccp application, using end-to-end ecn marks, = plus an edge-to-edge reservation. I guess I don't understand why someone = might be doing this] Thanks phil -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of = Georgios Karagiannis Sent: 15 November 2005 20:35 To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; tsvwg@ietf.org; nsis@ietf.org Subject: [NSIS] interoperability problems between end-to-end ECN = andedge-to-edge ECN Hi Bob Yes I agree, the admission control based on (pre-)congestion = notification and the severe congestion (or pre-emption) used in RMD and in your proposal are very similar. The main difference of your proposal compared to RMD is that the ECN re-marking is used instead of DSCP re-marking. During the tsvwg meeting, I have tried to emphasize that ECN is designed to be an end-to-end concept and not an edge-to-edge concept. When ECN is used for edge-to-edge purposes this might limit the current and future applicability of the (end-to-end) ECN concept. For example, the current and future applicability of the DCCP protocol might be restricted since streaming applications might not be able to use the complete semantics of the end-to-end ECN concept. This problem can become more severe if streaming applications will be using DCCP in combination with a QoS reservation (or a Diffserv based QoS support). Note that this reservation might not go end-to-end, but for example end-to-edge. Best Regards, Georgios On 11/10/2005, "Bob Briscoe" wrote: >TSVWG & NSIS, > >It's been pointed out that people on the list don't understand what my >original posting in this thread was about. I was replying to a point = made >by Georgios at the mike in TSVWG without giving context. > >Context >------- >It is about a difference in approach between RMD (in NSIS) and >pre-congestion notification (in TSVWG). Among other differences, this = one >is about re-marking on routers within the Diffserv region if they are >congested. > >In both cases, this re-marked traffic is measured for the aggregate >arriving at the egress of the Diffserv region and if above a threshold, >admission of new flows to that aggregate is blocked. > >The difference is that routers in the interior of the region re-mark >differently: >* RMD re-marks to another Diffserv codepoint and doesn't touch the ECN >field. * Pre-congestion notification re-marks to the CE codepoint of = ECN >and doesn't touch the DSCP. > >One of the reasons RMD didn't touch the ECN codepoint was so as not to >interfere with end-to-end congestion control of the *same* flow. > >The pre-congestion notification approach deliberately chooses to = re-mark >the ECN field, on the grounds that it is congestion that is being >signalled, albeit 'pre-congestion'. > >The draft says we think it very unlikely that anyone will be doing >end-to-end congestion control as well as reserving capacity for the = same >flow. But, we say if anyone can give a good reason why this might = happen, >we can add mechanism to allow both at once. But we don't want to add >complexity for what seems only a hypothetical requirement. > >So now, if you're interested, you can go back to the original posting = and >perhaps understand the context. > >Sorry about that. > >Then, I'd be interested to hear from anyone who can argue for = congestion >control within a reserved flow. > > > > >Bob > >PS. As well as wire protocol differences, there are important semantic >differences in the meaning of a re-marked packet, but we'll we'll try = to >reach consensus with the RMD authors on that off-line first then come = back >to the list with the conclusion. > > > >At 18:27 10/11/2005, IJ/ETH wrote: >>Hi All, this link may work better, Attila >> >>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-westberg-l= oadcntr-03.txt >> >> > -----Original Message----- >> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> > Sent: Thursday, November 10, 2005 6:46 PM >> > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) >> > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars = Westberg >> > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny); >> > tsvwg@ietf.org; nsis@ietf.org >> > Subject: Re: RMD & pre-congestion notification: How edge-edge and >> > end-end can interwork >> > >> > >> > >> > Hi Bob >> > >> > Thank you for your e-mail! >> > >> > Please note that during an IETF meeting in 2000, Lars >> > Westberg presented >> > an Internet draft, see bellow, that used the ECN bits for edge2edge >> > admission control purposes, but it could not become a WG draft. >> > >> > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt >> > >> > Best Regards, >> > Georgios >> > >> > >> > On 11/10/2005, "Bob Briscoe" wrote: >> > >> > >Attila, Georgios, >> > > >> > >[cross-posting tsvwg & nsis] >> > > >> > >Below is the mail I sent to you over a year ago solving your >> > concerns over >> > >interworking end-end & edge-edge ECN. >> > > >> > >The similar text below has been in >> > > since the initial = draft. >> > > >> > >As it says, if anyone can identify a genuine need to do e2e >> > congestion >> > >control within a reservation, we have a way to allow it. So >> > if you have a >> > >plausible reason for why anyone might ever want this, we are >> > certainly >> > >willing and able to accomodate you. But do you? >> > > >> > >We don't want to complicate the system if no-one will ever >> > need it. I can >> > >construct hypothetical scenarios where cc might be useful >> > even when you >> > >have reserved bandwidth, but I can't think of any practical use. >> > > >> > >If your concern is purely that we should not second-guess >> > what people might >> > >want in the future, you need not worry. Because if cc within >> > a resv were >> > >required, a simple extension to the e2e signalling protocol >> > (RSVP or NSIS) >> > >would allow the endpoints to say they wanted to use ECN >> > end-to-end. That >> > >could be added if the need arose. But I don't see the need >> > to add it now. >> > > >> > >" >> > >4.3. Egress gateways >> > > >> > > Egress gateways do the following tasks: >> > > >> > >---snip--- >> > > >> > > o Packet colouring - for CL packets, set the DSCP and >> > the ECN field >> > > to whatever has been agreed as appropriate for the >> > next domain. By >> > > default the ECN field is set to the Not-ECT >> > codepoint. Note that >> > > this results in the loss of the end-to-end meaning of the = ECN >> > > field. It can usually be assumed that end-to-end congestion >> > > control is unnecessary within an end-to-end >> > reservation. But if a >> > > genuine need is identified for end-to-end ECN >> > semantics within a >> > > reservation, then an alternative is to tunnel CL >> > packets across >> > > the CL-region, or to agree an extension to end-to-end >> > signalling >> > > to indicate that the microflow uses an ECN-capable >> > transport. We >> > > do not recommend such apparently unnecessary complexity. >> > > >> > >" >> > >It's really a question of what everyone believes the default >> > semantics of a >> > >reservation are today: >> > >a) end-to-end cc is not being used for reserved traffic? >> > >b) end-to-end cc is being used for reserved traffic? >> > > >> > >I believe, pragmatically, it is a). >> > > >> > >But perhaps you believe the current default position is (b)? If = the >> > >consensus of the TSVWG or NSIS w-gs is with you not me, we >> > would have to >> > >define extensions to RSVP and NSIS for the endpoints to flag >> > that they were >> > >NOT intending to use end-to-end cc. To reduce complexity, I >> > would want the >> > >default for the API to any new signalling stacks to be >> > REQUIRED to be NO >> > >end-to-end congestion control required. >> > > >> > >Then legacy hosts that want to use end-to-end cc would not >> > need to signal >> > >anything new. >> > >And if application writers using reservations said nothing and = their >> > >application was installed on an operating system compliant with = the >> > >signalling extension it would automatically signal that >> > end-to-end cc was >> > >not being used. App writers who wanted to use end-to-end cc within >> > >reservations would have to explicitly call the API to say so. >> > > >> > >Cheers >> > > >> > > >> > > >> > >Bob >> > > >> > >>From: Attila B=E1der (IJ/ETH) >> > >> >> > >>To: "'Bob Briscoe'" >> > >>Cc: "Lars Westberg (KI/EAB)" , >> > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" >> > , >> > >> gqs@jungle.bt.co.uk >> > >>Subject: RE: RE: Meeting to discuss QoS >> > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 >> > >>X-Mailer: Internet Mail Service (5.5.2657.72) >> > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC) >> > >>FILETIME=3D[0F6B35F0:01C48424] >> > >>X-MIME-Autoconverted: from quoted-printable to 8bit by >> > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 >> > >> >> > >>Hi Bob, >> > >> >> > >>Thank you for your answers, I will think of them. >> > > >> > >[BB 10/11/05]: Haven't seen any response since --- until >> > Georgios repeated >> > >the concern in the TSVWG mtg on Tuesday. >> > > >> > >>The work mentioned was not published, so I cannot send a >> > ref. now. The >> > >>contact person knows our investigation, even if not all the = details, >> > >>please let me know if you do not get answer from him. >> > >> >> > >>Best regards, Attila >> > >> >> > >> > -----Original Message----- >> > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >> > >> > Sent: Thursday, August 12, 2004 1:54 PM >> > >> > To: Attila B=E1der (IJ/ETH) >> > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; >> > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk >> > >> > Subject: RE: RE: Meeting to discuss QoS >> > >> > >> > >> > >> > >> > Attila, >> > >> > >> > >> > Sorry for delay - been meeting a submission deadline. >> > See below... >> > >> > >> > >> > At 15:58 06/08/04, IJ/ETH wrote: >> > >> > >Hi Bob, >> > >> > > >> > >> > >I apologize for the late answer, I was very busy during the >> > >> > summer and we >> > >> > >had to discuss your proposal. Yesterday we came together >> > >> > with Philip and >> > >> > >Lars for a discussion. >> > >> > > >> > >> > >We have the following main comments regarding the >> > solutions sent us: >> > >> > > >> > >> > >We have also investigated similar solutions. >> > >> > >> > >> > [BB] Refs? >> > >> > >> > >> > >[AB] The main problem we see with ECN marking is that it has >> > >> > end-to-end scope. >> > >> > >The default behavior of ECN assumes that the end host switch >> > >> > on/off the >> > >> > >marking. >> > >> > >> > >> > [BB] We aren't using the default behaviour. I thought >> > the paper makes this >> > >> > clear. It says we're using all three of the RSVP, DSCP and >> > >> > ECN /protocols/, >> > >> > but none of their /architectures/, that is, we're not using >> > >> > the Intserv, >> > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at >> > >> > the IP layer. >> > >> > The return path is an opaque object carried by the RSVP RESV >> > >> > from edge to >> > >> > edge. >> > >> > >> > >> > Traffic that has had a reservation signalled has ECT and a >> > >> > guaranteed DSCP >> > >> > turned on at the ingress gateway and turned off at the egress. >> > >> > >> > >> > Traffic not under a reservation (either not matching >> > filterspec, or >> > >> > matching but overflowing the token bucket) is policed to >> > >> > ensure it isn't >> > >> > using the guaranteed DSCP. But ECT isn't touched, allowing >> > >> > the end systems >> > >> > to control how congestion is handled. >> > >> > >> > >> > We have various (unresolved) options if ECT is already on >> > >> > when reserved >> > >> > packets arrive. Obviously we leave it on at ingress, but the >> > >> > question is >> > >> > how to know not to turn it off at egress. Two possibilities: >> > >> > - extend the signalling to say what to do at egress (but this >> > >> > doesn't cope >> > >> > with some packets in the reservation having ECT on & others = off). >> > >> > - tunnel between the gateways (wastes header space just to >> > >> > tunnel one bit) >> > >> > >> > > >> > >---Snip loads of further conversation--- >> > > >> > > >> > > >> > >_____________________________________________________________ >> > _______________ >> > >Notice: This contribution is the personal view of the author >> > and does not >> > >necessarily reflect the technical nor commercial direction of BT = plc. >> > >_____________________________________________________________ >> > _______________ >> > >Bob Briscoe, Networks Research >> > Centre, BT Research >> > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >> > +44 1473 645196 >> > > >> > > >> > > >________________________________________________________________________= ____ >Bob Briscoe, Networks Research Centre, BT = Research >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 = 645196 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 16 08:25:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNI7-0001Jp-KB; Wed, 16 Nov 2005 08:25:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNI6-0001Jh-4U; Wed, 16 Nov 2005 08:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24754; Wed, 16 Nov 2005 08:24:59 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcNZX-0007t8-6Z; Wed, 16 Nov 2005 08:43:35 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id jAGDNeEJ029549; Wed, 16 Nov 2005 14:23:40 +0100 (MET) Message-ID: <008101c5eab1$34425300$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: , , , References: Subject: Re: [NSIS] interoperability problems between end-to-end ECNandedge-to-edge ECN Date: Wed, 16 Nov 2005 11:41:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: -4.932 () ALL_TRUSTED, AWL, BAYES_00, FVGT_u_HAS_2LETTERFLDR, J_CHICKENPOX_57, J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 16 Nov 2005 14:25:30 +0100 (MET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id jAGDNeEJ029549 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 Content-Transfer-Encoding: quoted-printable Cc: lars.eggert@netlab.nec.de, "'Phelan, Tom'" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Phil Please see bellow! > > Please can you explain the scenario a bit more. I don't understand it y= et > [I think you have a dccp application, using end-to-end ecn marks, plus = an=20 > edge-to-edge reservation. > I guess I don't understand why someone might be doing this] DCCP can be used as transport protocol for streaming applications. DCCP u= ses end-to-end ECN for congestion control support. A streaming application might need QoS support. Please note that this QoS= =20 support can be provided either end-to-end or end-to-edge or edge-to-edge. This depends on the operators=20 that are willing to support such streaming applications. Now suppose that such a streaming application that uses DCCP and needs Qo= S=20 support needs to be processed by a domain that will support the edge-to-edge ECN semantics, that you are proposing. Maybe the DCCP folks could help us in this discussion! Best regards, Georgios > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of= =20 > Georgios Karagiannis > Sent: 15 November 2005 20:35 > To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; tsvwg@ietf.org; nsis@ietf.org > Subject: [NSIS] interoperability problems between end-to-end ECN=20 > andedge-to-edge ECN > > > Hi Bob > > Yes I agree, the admission control based on (pre-)congestion notificati= on > and the severe congestion (or pre-emption) used in RMD and in your > proposal are very similar. The main difference of your proposal compare= d > to RMD is that the ECN re-marking is used instead of DSCP re-marking. > > During the tsvwg meeting, I have tried to emphasize that ECN is designe= d > to be an end-to-end concept and not an edge-to-edge concept. > When ECN is used for edge-to-edge purposes this might > limit the current and future applicability of the > (end-to-end) ECN concept. > > > For example, the current and future applicability of the DCCP protocol > might be restricted since streaming applications > might not be able to use the complete semantics of the end-to-end ECN > concept. > This problem can become more severe if streaming applications will be > using DCCP in combination with a QoS reservation (or a Diffserv based > QoS support). Note that this reservation might not go end-to-end, but > for example end-to-edge. > > > Best Regards, > Georgios > > On 11/10/2005, "Bob Briscoe" wrote: > >>TSVWG & NSIS, >> >>It's been pointed out that people on the list don't understand what my >>original posting in this thread was about. I was replying to a point ma= de >>by Georgios at the mike in TSVWG without giving context. >> >>Context >>------- >>It is about a difference in approach between RMD (in NSIS) and >>pre-congestion notification (in TSVWG). Among other differences, this o= ne >>is about re-marking on routers within the Diffserv region if they are >>congested. >> >>In both cases, this re-marked traffic is measured for the aggregate >>arriving at the egress of the Diffserv region and if above a threshold, >>admission of new flows to that aggregate is blocked. >> >>The difference is that routers in the interior of the region re-mark >>differently: >>* RMD re-marks to another Diffserv codepoint and doesn't touch the ECN >>field. * Pre-congestion notification re-marks to the CE codepoint of EC= N >>and doesn't touch the DSCP. >> >>One of the reasons RMD didn't touch the ECN codepoint was so as not to >>interfere with end-to-end congestion control of the *same* flow. >> >>The pre-congestion notification approach deliberately chooses to re-mar= k >>the ECN field, on the grounds that it is congestion that is being >>signalled, albeit 'pre-congestion'. >> >>The draft says we think it very unlikely that anyone will be doing >>end-to-end congestion control as well as reserving capacity for the sam= e >>flow. But, we say if anyone can give a good reason why this might happe= n, >>we can add mechanism to allow both at once. But we don't want to add >>complexity for what seems only a hypothetical requirement. >> >>So now, if you're interested, you can go back to the original posting a= nd >>perhaps understand the context. >> >>Sorry about that. >> >>Then, I'd be interested to hear from anyone who can argue for congestio= n >>control within a reserved flow. >> >> >> >> >>Bob >> >>PS. As well as wire protocol differences, there are important semantic >>differences in the meaning of a re-marked packet, but we'll we'll try t= o >>reach consensus with the RMD authors on that off-line first then come b= ack >>to the list with the conclusion. >> >> >> >>At 18:27 10/11/2005, IJ/ETH wrote: >>>Hi All, this link may work better, Attila >>> >>>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-westberg-= loadcntr-03.txt >>> >>> > -----Original Message----- >>> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>> > Sent: Thursday, November 10, 2005 6:46 PM >>> > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) >>> > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars Westbe= rg >>> > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny); >>> > tsvwg@ietf.org; nsis@ietf.org >>> > Subject: Re: RMD & pre-congestion notification: How edge-edge and >>> > end-end can interwork >>> > >>> > >>> > >>> > Hi Bob >>> > >>> > Thank you for your e-mail! >>> > >>> > Please note that during an IETF meeting in 2000, Lars >>> > Westberg presented >>> > an Internet draft, see bellow, that used the ECN bits for edge2edge >>> > admission control purposes, but it could not become a WG draft. >>> > >>> > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt >>> > >>> > Best Regards, >>> > Georgios >>> > >>> > >>> > On 11/10/2005, "Bob Briscoe" wrote: >>> > >>> > >Attila, Georgios, >>> > > >>> > >[cross-posting tsvwg & nsis] >>> > > >>> > >Below is the mail I sent to you over a year ago solving your >>> > concerns over >>> > >interworking end-end & edge-edge ECN. >>> > > >>> > >The similar text below has been in >>> > > since the initial dra= ft. >>> > > >>> > >As it says, if anyone can identify a genuine need to do e2e >>> > congestion >>> > >control within a reservation, we have a way to allow it. So >>> > if you have a >>> > >plausible reason for why anyone might ever want this, we are >>> > certainly >>> > >willing and able to accomodate you. But do you? >>> > > >>> > >We don't want to complicate the system if no-one will ever >>> > need it. I can >>> > >construct hypothetical scenarios where cc might be useful >>> > even when you >>> > >have reserved bandwidth, but I can't think of any practical use. >>> > > >>> > >If your concern is purely that we should not second-guess >>> > what people might >>> > >want in the future, you need not worry. Because if cc within >>> > a resv were >>> > >required, a simple extension to the e2e signalling protocol >>> > (RSVP or NSIS) >>> > >would allow the endpoints to say they wanted to use ECN >>> > end-to-end. That >>> > >could be added if the need arose. But I don't see the need >>> > to add it now. >>> > > >>> > >" >>> > >4.3. Egress gateways >>> > > >>> > > Egress gateways do the following tasks: >>> > > >>> > >---snip--- >>> > > >>> > > o Packet colouring - for CL packets, set the DSCP and >>> > the ECN field >>> > > to whatever has been agreed as appropriate for the >>> > next domain. By >>> > > default the ECN field is set to the Not-ECT >>> > codepoint. Note that >>> > > this results in the loss of the end-to-end meaning of the E= CN >>> > > field. It can usually be assumed that end-to-end congestion >>> > > control is unnecessary within an end-to-end >>> > reservation. But if a >>> > > genuine need is identified for end-to-end ECN >>> > semantics within a >>> > > reservation, then an alternative is to tunnel CL >>> > packets across >>> > > the CL-region, or to agree an extension to end-to-end >>> > signalling >>> > > to indicate that the microflow uses an ECN-capable >>> > transport. We >>> > > do not recommend such apparently unnecessary complexity. >>> > > >>> > >" >>> > >It's really a question of what everyone believes the default >>> > semantics of a >>> > >reservation are today: >>> > >a) end-to-end cc is not being used for reserved traffic? >>> > >b) end-to-end cc is being used for reserved traffic? >>> > > >>> > >I believe, pragmatically, it is a). >>> > > >>> > >But perhaps you believe the current default position is (b)? If th= e >>> > >consensus of the TSVWG or NSIS w-gs is with you not me, we >>> > would have to >>> > >define extensions to RSVP and NSIS for the endpoints to flag >>> > that they were >>> > >NOT intending to use end-to-end cc. To reduce complexity, I >>> > would want the >>> > >default for the API to any new signalling stacks to be >>> > REQUIRED to be NO >>> > >end-to-end congestion control required. >>> > > >>> > >Then legacy hosts that want to use end-to-end cc would not >>> > need to signal >>> > >anything new. >>> > >And if application writers using reservations said nothing and the= ir >>> > >application was installed on an operating system compliant with th= e >>> > >signalling extension it would automatically signal that >>> > end-to-end cc was >>> > >not being used. App writers who wanted to use end-to-end cc within >>> > >reservations would have to explicitly call the API to say so. >>> > > >>> > >Cheers >>> > > >>> > > >>> > > >>> > >Bob >>> > > >>> > >>From: Attila B=E1der (IJ/ETH) >>> > >> >>> > >>To: "'Bob Briscoe'" >>> > >>Cc: "Lars Westberg (KI/EAB)" , >>> > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" >>> > , >>> > >> gqs@jungle.bt.co.uk >>> > >>Subject: RE: RE: Meeting to discuss QoS >>> > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 >>> > >>X-Mailer: Internet Mail Service (5.5.2657.72) >>> > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC) >>> > >>FILETIME=3D[0F6B35F0:01C48424] >>> > >>X-MIME-Autoconverted: from quoted-printable to 8bit by >>> > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 >>> > >> >>> > >>Hi Bob, >>> > >> >>> > >>Thank you for your answers, I will think of them. >>> > > >>> > >[BB 10/11/05]: Haven't seen any response since --- until >>> > Georgios repeated >>> > >the concern in the TSVWG mtg on Tuesday. >>> > > >>> > >>The work mentioned was not published, so I cannot send a >>> > ref. now. The >>> > >>contact person knows our investigation, even if not all the detai= ls, >>> > >>please let me know if you do not get answer from him. >>> > >> >>> > >>Best regards, Attila >>> > >> >>> > >> > -----Original Message----- >>> > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >>> > >> > Sent: Thursday, August 12, 2004 1:54 PM >>> > >> > To: Attila B=E1der (IJ/ETH) >>> > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; >>> > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk >>> > >> > Subject: RE: RE: Meeting to discuss QoS >>> > >> > >>> > >> > >>> > >> > Attila, >>> > >> > >>> > >> > Sorry for delay - been meeting a submission deadline. >>> > See below... >>> > >> > >>> > >> > At 15:58 06/08/04, IJ/ETH wrote: >>> > >> > >Hi Bob, >>> > >> > > >>> > >> > >I apologize for the late answer, I was very busy during the >>> > >> > summer and we >>> > >> > >had to discuss your proposal. Yesterday we came together >>> > >> > with Philip and >>> > >> > >Lars for a discussion. >>> > >> > > >>> > >> > >We have the following main comments regarding the >>> > solutions sent us: >>> > >> > > >>> > >> > >We have also investigated similar solutions. >>> > >> > >>> > >> > [BB] Refs? >>> > >> > >>> > >> > >[AB] The main problem we see with ECN marking is that it has >>> > >> > end-to-end scope. >>> > >> > >The default behavior of ECN assumes that the end host switch >>> > >> > on/off the >>> > >> > >marking. >>> > >> > >>> > >> > [BB] We aren't using the default behaviour. I thought >>> > the paper makes this >>> > >> > clear. It says we're using all three of the RSVP, DSCP and >>> > >> > ECN /protocols/, >>> > >> > but none of their /architectures/, that is, we're not using >>> > >> > the Intserv, >>> > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at >>> > >> > the IP layer. >>> > >> > The return path is an opaque object carried by the RSVP RESV >>> > >> > from edge to >>> > >> > edge. >>> > >> > >>> > >> > Traffic that has had a reservation signalled has ECT and a >>> > >> > guaranteed DSCP >>> > >> > turned on at the ingress gateway and turned off at the egress. >>> > >> > >>> > >> > Traffic not under a reservation (either not matching >>> > filterspec, or >>> > >> > matching but overflowing the token bucket) is policed to >>> > >> > ensure it isn't >>> > >> > using the guaranteed DSCP. But ECT isn't touched, allowing >>> > >> > the end systems >>> > >> > to control how congestion is handled. >>> > >> > >>> > >> > We have various (unresolved) options if ECT is already on >>> > >> > when reserved >>> > >> > packets arrive. Obviously we leave it on at ingress, but the >>> > >> > question is >>> > >> > how to know not to turn it off at egress. Two possibilities: >>> > >> > - extend the signalling to say what to do at egress (but this >>> > >> > doesn't cope >>> > >> > with some packets in the reservation having ECT on & others of= f). >>> > >> > - tunnel between the gateways (wastes header space just to >>> > >> > tunnel one bit) >>> > >> > >>> > > >>> > >---Snip loads of further conversation--- >>> > > >>> > > >>> > > >>> > >_____________________________________________________________ >>> > _______________ >>> > >Notice: This contribution is the personal view of the author >>> > and does not >>> > >necessarily reflect the technical nor commercial direction of BT p= lc. >>> > >_____________________________________________________________ >>> > _______________ >>> > >Bob Briscoe, Networks Research >>> > Centre, BT Research >>> > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >>> > +44 1473 645196 >>> > > >>> > > >>> > >> >>_______________________________________________________________________= _____ >>Bob Briscoe, Networks Research Centre, BT=20 >>Research >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473=20 >>645196 >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 16 11:07:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPoc-00058q-43; Wed, 16 Nov 2005 11:07:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPoa-000579-Gx; Wed, 16 Nov 2005 11:07:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06459; Wed, 16 Nov 2005 11:06:43 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcQ62-0006j3-Vj; Wed, 16 Nov 2005 11:25:19 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id jAGG78qV008659; Wed, 16 Nov 2005 17:07:08 +0100 (MET) Message-ID: <012f01c5eac7$cc27a970$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: , , References: Subject: Re: [NSIS] interoperability problems between end-to-end ECNandedge-to-edge ECN Date: Wed, 16 Nov 2005 17:07:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: -4.929 () ALL_TRUSTED, AWL, BAYES_00, FVGT_u_HAS_2LETTERFLDR, J_CHICKENPOX_57, J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 16 Nov 2005 17:07:12 +0100 (MET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id jAGG78qV008659 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Phil Here is a more concrete example. Consider that the following streaming application has to be supported: Video-streaming with rate adaptive coding application that can adapt the bandwidth but for a feasible service quality it requires a minimum bandwidth. The minimum bandwidth is reserved because otherwise the service is useless. If the network has more capacity it can utilize that and give the enduser a higher quality with better end-user experience. This streaming application can very well use ECN and RSVP to handle the=20 bandwidth management. Best Regards, Georgios ----- Original Message -----=20 From: To: ; ; ;=20 Sent: Wednesday, November 16, 2005 10:58 AM Subject: RE: [NSIS] interoperability problems between end-to-end=20 ECNandedge-to-edge ECN > Georgios > > Please can you explain the scenario a bit more. I don't understand it y= et=20 > [I think you have a dccp application, using end-to-end ecn marks, plus = an=20 > edge-to-edge reservation. I guess I don't understand why someone might = be=20 > doing this] > > Thanks > phil > > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of= =20 > Georgios Karagiannis > Sent: 15 November 2005 20:35 > To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; tsvwg@ietf.org; nsis@ietf.org > Subject: [NSIS] interoperability problems between end-to-end ECN=20 > andedge-to-edge ECN > > > Hi Bob > > Yes I agree, the admission control based on (pre-)congestion notificati= on > and the severe congestion (or pre-emption) used in RMD and in your > proposal are very similar. The main difference of your proposal compare= d > to RMD is that the ECN re-marking is used instead of DSCP re-marking. > > During the tsvwg meeting, I have tried to emphasize that ECN is designe= d > to be an end-to-end concept and not an edge-to-edge concept. > When ECN is used for edge-to-edge purposes this might > limit the current and future applicability of the > (end-to-end) ECN concept. > > > For example, the current and future applicability of the DCCP protocol > might be restricted since streaming applications > might not be able to use the complete semantics of the end-to-end ECN > concept. > This problem can become more severe if streaming applications will be > using DCCP in combination with a QoS reservation (or a Diffserv based > QoS support). Note that this reservation might not go end-to-end, but > for example end-to-edge. > > > Best Regards, > Georgios > > On 11/10/2005, "Bob Briscoe" wrote: > >>TSVWG & NSIS, >> >>It's been pointed out that people on the list don't understand what my >>original posting in this thread was about. I was replying to a point ma= de >>by Georgios at the mike in TSVWG without giving context. >> >>Context >>------- >>It is about a difference in approach between RMD (in NSIS) and >>pre-congestion notification (in TSVWG). Among other differences, this o= ne >>is about re-marking on routers within the Diffserv region if they are >>congested. >> >>In both cases, this re-marked traffic is measured for the aggregate >>arriving at the egress of the Diffserv region and if above a threshold, >>admission of new flows to that aggregate is blocked. >> >>The difference is that routers in the interior of the region re-mark >>differently: >>* RMD re-marks to another Diffserv codepoint and doesn't touch the ECN >>field. * Pre-congestion notification re-marks to the CE codepoint of EC= N >>and doesn't touch the DSCP. >> >>One of the reasons RMD didn't touch the ECN codepoint was so as not to >>interfere with end-to-end congestion control of the *same* flow. >> >>The pre-congestion notification approach deliberately chooses to re-mar= k >>the ECN field, on the grounds that it is congestion that is being >>signalled, albeit 'pre-congestion'. >> >>The draft says we think it very unlikely that anyone will be doing >>end-to-end congestion control as well as reserving capacity for the sam= e >>flow. But, we say if anyone can give a good reason why this might happe= n, >>we can add mechanism to allow both at once. But we don't want to add >>complexity for what seems only a hypothetical requirement. >> >>So now, if you're interested, you can go back to the original posting a= nd >>perhaps understand the context. >> >>Sorry about that. >> >>Then, I'd be interested to hear from anyone who can argue for congestio= n >>control within a reserved flow. >> >> >> >> >>Bob >> >>PS. As well as wire protocol differences, there are important semantic >>differences in the meaning of a re-marked packet, but we'll we'll try t= o >>reach consensus with the RMD authors on that off-line first then come b= ack >>to the list with the conclusion. >> >> >> >>At 18:27 10/11/2005, IJ/ETH wrote: >>>Hi All, this link may work better, Attila >>> >>>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-westberg-= loadcntr-03.txt >>> >>> > -----Original Message----- >>> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>> > Sent: Thursday, November 10, 2005 6:46 PM >>> > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) >>> > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars Westbe= rg >>> > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny); >>> > tsvwg@ietf.org; nsis@ietf.org >>> > Subject: Re: RMD & pre-congestion notification: How edge-edge and >>> > end-end can interwork >>> > >>> > >>> > >>> > Hi Bob >>> > >>> > Thank you for your e-mail! >>> > >>> > Please note that during an IETF meeting in 2000, Lars >>> > Westberg presented >>> > an Internet draft, see bellow, that used the ECN bits for edge2edge >>> > admission control purposes, but it could not become a WG draft. >>> > >>> > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt >>> > >>> > Best Regards, >>> > Georgios >>> > >>> > >>> > On 11/10/2005, "Bob Briscoe" wrote: >>> > >>> > >Attila, Georgios, >>> > > >>> > >[cross-posting tsvwg & nsis] >>> > > >>> > >Below is the mail I sent to you over a year ago solving your >>> > concerns over >>> > >interworking end-end & edge-edge ECN. >>> > > >>> > >The similar text below has been in >>> > > since the initial dra= ft. >>> > > >>> > >As it says, if anyone can identify a genuine need to do e2e >>> > congestion >>> > >control within a reservation, we have a way to allow it. So >>> > if you have a >>> > >plausible reason for why anyone might ever want this, we are >>> > certainly >>> > >willing and able to accomodate you. But do you? >>> > > >>> > >We don't want to complicate the system if no-one will ever >>> > need it. I can >>> > >construct hypothetical scenarios where cc might be useful >>> > even when you >>> > >have reserved bandwidth, but I can't think of any practical use. >>> > > >>> > >If your concern is purely that we should not second-guess >>> > what people might >>> > >want in the future, you need not worry. Because if cc within >>> > a resv were >>> > >required, a simple extension to the e2e signalling protocol >>> > (RSVP or NSIS) >>> > >would allow the endpoints to say they wanted to use ECN >>> > end-to-end. That >>> > >could be added if the need arose. But I don't see the need >>> > to add it now. >>> > > >>> > >" >>> > >4.3. Egress gateways >>> > > >>> > > Egress gateways do the following tasks: >>> > > >>> > >---snip--- >>> > > >>> > > o Packet colouring - for CL packets, set the DSCP and >>> > the ECN field >>> > > to whatever has been agreed as appropriate for the >>> > next domain. By >>> > > default the ECN field is set to the Not-ECT >>> > codepoint. Note that >>> > > this results in the loss of the end-to-end meaning of the E= CN >>> > > field. It can usually be assumed that end-to-end congestion >>> > > control is unnecessary within an end-to-end >>> > reservation. But if a >>> > > genuine need is identified for end-to-end ECN >>> > semantics within a >>> > > reservation, then an alternative is to tunnel CL >>> > packets across >>> > > the CL-region, or to agree an extension to end-to-end >>> > signalling >>> > > to indicate that the microflow uses an ECN-capable >>> > transport. We >>> > > do not recommend such apparently unnecessary complexity. >>> > > >>> > >" >>> > >It's really a question of what everyone believes the default >>> > semantics of a >>> > >reservation are today: >>> > >a) end-to-end cc is not being used for reserved traffic? >>> > >b) end-to-end cc is being used for reserved traffic? >>> > > >>> > >I believe, pragmatically, it is a). >>> > > >>> > >But perhaps you believe the current default position is (b)? If th= e >>> > >consensus of the TSVWG or NSIS w-gs is with you not me, we >>> > would have to >>> > >define extensions to RSVP and NSIS for the endpoints to flag >>> > that they were >>> > >NOT intending to use end-to-end cc. To reduce complexity, I >>> > would want the >>> > >default for the API to any new signalling stacks to be >>> > REQUIRED to be NO >>> > >end-to-end congestion control required. >>> > > >>> > >Then legacy hosts that want to use end-to-end cc would not >>> > need to signal >>> > >anything new. >>> > >And if application writers using reservations said nothing and the= ir >>> > >application was installed on an operating system compliant with th= e >>> > >signalling extension it would automatically signal that >>> > end-to-end cc was >>> > >not being used. App writers who wanted to use end-to-end cc within >>> > >reservations would have to explicitly call the API to say so. >>> > > >>> > >Cheers >>> > > >>> > > >>> > > >>> > >Bob >>> > > >>> > >>From: Attila B=E1der (IJ/ETH) >>> > >> >>> > >>To: "'Bob Briscoe'" >>> > >>Cc: "Lars Westberg (KI/EAB)" , >>> > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" >>> > , >>> > >> gqs@jungle.bt.co.uk >>> > >>Subject: RE: RE: Meeting to discuss QoS >>> > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 >>> > >>X-Mailer: Internet Mail Service (5.5.2657.72) >>> > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC) >>> > >>FILETIME=3D[0F6B35F0:01C48424] >>> > >>X-MIME-Autoconverted: from quoted-printable to 8bit by >>> > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 >>> > >> >>> > >>Hi Bob, >>> > >> >>> > >>Thank you for your answers, I will think of them. >>> > > >>> > >[BB 10/11/05]: Haven't seen any response since --- until >>> > Georgios repeated >>> > >the concern in the TSVWG mtg on Tuesday. >>> > > >>> > >>The work mentioned was not published, so I cannot send a >>> > ref. now. The >>> > >>contact person knows our investigation, even if not all the detai= ls, >>> > >>please let me know if you do not get answer from him. >>> > >> >>> > >>Best regards, Attila >>> > >> >>> > >> > -----Original Message----- >>> > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >>> > >> > Sent: Thursday, August 12, 2004 1:54 PM >>> > >> > To: Attila B=E1der (IJ/ETH) >>> > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl; >>> > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk >>> > >> > Subject: RE: RE: Meeting to discuss QoS >>> > >> > >>> > >> > >>> > >> > Attila, >>> > >> > >>> > >> > Sorry for delay - been meeting a submission deadline. >>> > See below... >>> > >> > >>> > >> > At 15:58 06/08/04, IJ/ETH wrote: >>> > >> > >Hi Bob, >>> > >> > > >>> > >> > >I apologize for the late answer, I was very busy during the >>> > >> > summer and we >>> > >> > >had to discuss your proposal. Yesterday we came together >>> > >> > with Philip and >>> > >> > >Lars for a discussion. >>> > >> > > >>> > >> > >We have the following main comments regarding the >>> > solutions sent us: >>> > >> > > >>> > >> > >We have also investigated similar solutions. >>> > >> > >>> > >> > [BB] Refs? >>> > >> > >>> > >> > >[AB] The main problem we see with ECN marking is that it has >>> > >> > end-to-end scope. >>> > >> > >The default behavior of ECN assumes that the end host switch >>> > >> > on/off the >>> > >> > >marking. >>> > >> > >>> > >> > [BB] We aren't using the default behaviour. I thought >>> > the paper makes this >>> > >> > clear. It says we're using all three of the RSVP, DSCP and >>> > >> > ECN /protocols/, >>> > >> > but none of their /architectures/, that is, we're not using >>> > >> > the Intserv, >>> > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at >>> > >> > the IP layer. >>> > >> > The return path is an opaque object carried by the RSVP RESV >>> > >> > from edge to >>> > >> > edge. >>> > >> > >>> > >> > Traffic that has had a reservation signalled has ECT and a >>> > >> > guaranteed DSCP >>> > >> > turned on at the ingress gateway and turned off at the egress. >>> > >> > >>> > >> > Traffic not under a reservation (either not matching >>> > filterspec, or >>> > >> > matching but overflowing the token bucket) is policed to >>> > >> > ensure it isn't >>> > >> > using the guaranteed DSCP. But ECT isn't touched, allowing >>> > >> > the end systems >>> > >> > to control how congestion is handled. >>> > >> > >>> > >> > We have various (unresolved) options if ECT is already on >>> > >> > when reserved >>> > >> > packets arrive. Obviously we leave it on at ingress, but the >>> > >> > question is >>> > >> > how to know not to turn it off at egress. Two possibilities: >>> > >> > - extend the signalling to say what to do at egress (but this >>> > >> > doesn't cope >>> > >> > with some packets in the reservation having ECT on & others of= f). >>> > >> > - tunnel between the gateways (wastes header space just to >>> > >> > tunnel one bit) >>> > >> > >>> > > >>> > >---Snip loads of further conversation--- >>> > > >>> > > >>> > > >>> > >_____________________________________________________________ >>> > _______________ >>> > >Notice: This contribution is the personal view of the author >>> > and does not >>> > >necessarily reflect the technical nor commercial direction of BT p= lc. >>> > >_____________________________________________________________ >>> > _______________ >>> > >Bob Briscoe, Networks Research >>> > Centre, BT Research >>> > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >>> > +44 1473 645196 >>> > > >>> > > >>> > >> >>_______________________________________________________________________= _____ >>Bob Briscoe, Networks Research Centre, BT=20 >>Research >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473=20 >>645196 >> >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 17 05:08:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecggp-0007w0-Rn; Thu, 17 Nov 2005 05:08:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecggo-0007vs-1R; Thu, 17 Nov 2005 05:08:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11061; Thu, 17 Nov 2005 05:07:48 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcgyJ-00031R-7I; Thu, 17 Nov 2005 05:26:34 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F3DFA4F0075; Thu, 17 Nov 2005 11:08:08 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 11:06:16 +0100 Content-class: urn:content-classes:message Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems betweenend-to-endECNandedge-to-edge ECN MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2005 11:06:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: [Tsvwg] Re: [NSIS] interoperability problems betweenend-to-endECNandedge-to-edge ECN Thread-Index: AcXqyG6A/MIdIVuPTgytUDFtvI1o8gAisoWAAAJKsBA= From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: , , , , X-OriginalArrivalTime: 17 Nov 2005 10:06:16.0595 (UTC) FILETIME=[8C766630:01C5EB5E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4863a9796402a44fdb52482f353618fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi All,=20 Here you assume, that traffic types might using end-to-end ECN will = never are subject of pre-congestion ECN marking and vica versa. If you = want to use ECN field edge-to-edge in different way than the current = standard, I think that it must be ensured that end nodes will not use = ECN. Or end-to-end usage of ECN is not affected by local use.=20 Best regards, Attila > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] > Sent: Thursday, November 17, 2005 9:51 AM > To: karagian@cs.utwente.nl; philip.eardley@bt.com; tsvwg@ietf.org; > nsis@ietf.org > Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems > betweenend-to-endECNandedge-to-edge ECN >=20 >=20 >=20 >=20 >=20 > If you send more than your reservered amount you have no=20 > guarentee on how the network will treat the excess traffic -=20 > but many people might just drop the excess - or treat it as=20 > the lowest of the low (worse than best effort - higher drop=20 > and latency) - so ECN would hardly help then. Certainly=20 > packet re-ordering could also occur giving higher jitter,=20 > because in a general case you process your reservered and BE=20 > traffic in different ways >=20 > Further, users value stability more than anything else, expts=20 > have shown that users would rather the video run at the=20 > lowest (mininum) bandwidth than fluxuate up and then down -=20 > ie lower stable network quality gives a higher user=20 > experianced quality than average higher quality=20 >=20 > Lou >=20 > > -----Original Message----- > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org]=20 > > On Behalf Of Georgios Karagiannis > > Sent: 16 November 2005 16:07 > > To: Eardley,PL,Philip,CXR9 R; tsvwg@ietf.org; nsis@ietf.org > > Subject: [Tsvwg] Re: [NSIS] interoperability problems between=20 > > end-to-endECNandedge-to-edge ECN > >=20 > >=20 > > Hi Phil > >=20 > > Here is a more concrete example. > > Consider that the following streaming application has to be=20 > > supported: Video-streaming with rate adaptive coding=20 > > application that can adapt the bandwidth but for a feasible=20 > > service quality it requires a minimum bandwidth. > >=20 > > The minimum bandwidth is reserved because otherwise the > > service is useless. If the network has more capacity it can=20 > > utilize that and give the enduser a higher quality with=20 > > better end-user experience. > >=20 > > This streaming application can very well use ECN and RSVP to=20 > > handle the=20 > > bandwidth > > management. > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > >=20 > >=20 > > ----- Original Message -----=20 > > From: > > To: ; ;=20 > > ;=20 > > > > Sent: Wednesday, November 16, 2005 10:58 AM > > Subject: RE: [NSIS] interoperability problems between end-to-end=20 > > ECNandedge-to-edge ECN > >=20 > >=20 > > > Georgios > > > > > > Please can you explain the scenario a bit more. I don't=20 > > understand it=20 > > > yet > > > [I think you have a dccp application, using end-to-end ecn=20 > > marks, plus an=20 > > > edge-to-edge reservation. I guess I don't understand why=20 > > someone might be=20 > > > doing this] > > > > > > Thanks > > > phil > > > > > > -----Original Message----- > > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > > On Behalf=20 > > > Of > > > Georgios Karagiannis > > > Sent: 15 November 2005 20:35 > > > To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; tsvwg@ietf.org; nsis@ietf.org > > > Subject: [NSIS] interoperability problems between end-to-end ECN=20 > > > andedge-to-edge ECN > > > > > > > > > Hi Bob > > > > > > Yes I agree, the admission control based on (pre-)congestion=20 > > > notification and the severe congestion (or pre-emption)=20 > used in RMD=20 > > > and in your proposal are very similar. The main=20 > difference of your=20 > > > proposal compared to RMD is that the ECN re-marking is used=20 > > instead of=20 > > > DSCP re-marking. > > > > > > During the tsvwg meeting, I have tried to emphasize that ECN is=20 > > > designed to be an end-to-end concept and not an=20 > > edge-to-edge concept.=20 > > > When ECN is used for edge-to-edge purposes this might limit the=20 > > > current and future applicability of the > > > (end-to-end) ECN concept. > > > > > > > > > For example, the current and future applicability of the=20 > > DCCP protocol=20 > > > might be restricted since streaming applications might not=20 > > be able to=20 > > > use the complete semantics of the end-to-end ECN concept. > > > This problem can become more severe if streaming=20 > > applications will be > > > using DCCP in combination with a QoS reservation (or a=20 > > Diffserv based > > > QoS support). Note that this reservation might not go=20 > > end-to-end, but > > > for example end-to-edge. > > > > > > > > > Best Regards, > > > Georgios > > > > > > On 11/10/2005, "Bob Briscoe" wrote: > > > > > >>TSVWG & NSIS, > > >> > > >>It's been pointed out that people on the list don't=20 > > understand what my=20 > > >>original posting in this thread was about. I was replying=20 > > to a point=20 > > >>made by Georgios at the mike in TSVWG without giving context. > > >> > > >>Context > > >>------- > > >>It is about a difference in approach between RMD (in NSIS) and=20 > > >>pre-congestion notification (in TSVWG). Among other=20 > > differences, this=20 > > >>one is about re-marking on routers within the Diffserv=20 > > region if they=20 > > >>are congested. > > >> > > >>In both cases, this re-marked traffic is measured for the=20 > aggregate=20 > > >>arriving at the egress of the Diffserv region and if above a=20 > > >>threshold, admission of new flows to that aggregate is blocked. > > >> > > >>The difference is that routers in the interior of the=20 > region re-mark > > >>differently: > > >>* RMD re-marks to another Diffserv codepoint and doesn't=20 > > touch the ECN=20 > > >>field. * Pre-congestion notification re-marks to the CE=20 > > codepoint of=20 > > >>ECN and doesn't touch the DSCP. > > >> > > >>One of the reasons RMD didn't touch the ECN codepoint was=20 > > so as not to=20 > > >>interfere with end-to-end congestion control of the *same* flow. > > >> > > >>The pre-congestion notification approach deliberately chooses to=20 > > >>re-mark the ECN field, on the grounds that it is=20 > congestion that is=20 > > >>being signalled, albeit 'pre-congestion'. > > >> > > >>The draft says we think it very unlikely that anyone will=20 > be doing=20 > > >>end-to-end congestion control as well as reserving=20 > capacity for the=20 > > >>same flow. But, we say if anyone can give a good reason why=20 > > this might=20 > > >>happen, we can add mechanism to allow both at once. But we=20 > > don't want=20 > > >>to add complexity for what seems only a hypothetical requirement. > > >> > > >>So now, if you're interested, you can go back to the=20 > > original posting=20 > > >>and perhaps understand the context. > > >> > > >>Sorry about that. > > >> > > >>Then, I'd be interested to hear from anyone who can argue for=20 > > >>congestion control within a reserved flow. > > >> > > >> > > >> > > >> > > >>Bob > > >> > > >>PS. As well as wire protocol differences, there are=20 > > important semantic=20 > > >>differences in the meaning of a re-marked packet, but we'll=20 > > we'll try=20 > > >>to reach consensus with the RMD authors on that off-line=20 > first then=20 > > >>come back to the list with the conclusion. > > >> > > >> > > >> > > >>At 18:27 10/11/2005, IJ/ETH wrote: > > >>>Hi All, this link may work better, Attila > > >>> > > >>>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draf > > t-westberg > > >>>-loadcntr-03.txt > > >>> > > >>> > -----Original Message----- > > >>> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >>> > Sent: Thursday, November 10, 2005 6:46 PM > > >>> > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) > > >>> > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars=20 > > >>> > Westberg (KI/EAB); Francois Le Faucheur (flefauch);=20 > Anna Charny=20 > > >>> > (acharny); tsvwg@ietf.org; nsis@ietf.org > > >>> > Subject: Re: RMD & pre-congestion notification: How=20 > > edge-edge and=20 > > >>> > end-end can interwork > > >>> > > > >>> > > > >>> > > > >>> > Hi Bob > > >>> > > > >>> > Thank you for your e-mail! > > >>> > > > >>> > Please note that during an IETF meeting in 2000, Lars=20 > Westberg=20 > > >>> > presented an Internet draft, see bellow, that used=20 > the ECN bits=20 > > >>> > for edge2edge admission control purposes, but it could=20 > > not become=20 > > >>> > a WG draft. > > >>> > > > >>> >=20 > > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt > > >>> > > > >>> > Best Regards, > > >>> > Georgios > > >>> > > > >>> > > > >>> > On 11/10/2005, "Bob Briscoe" wrote: > > >>> > > > >>> > >Attila, Georgios, > > >>> > > > > >>> > >[cross-posting tsvwg & nsis] > > >>> > > > > >>> > >Below is the mail I sent to you over a year ago solving your > > >>> > concerns over > > >>> > >interworking end-end & edge-edge ECN. > > >>> > > > > >>> > >The similar text below has been in=20 > > >>> > > since=20 > the initial=20 > > >>> > >draft. > > >>> > > > > >>> > >As it says, if anyone can identify a genuine need to do e2e > > >>> > congestion > > >>> > >control within a reservation, we have a way to allow it. So > > >>> > if you have a > > >>> > >plausible reason for why anyone might ever want this, we are > > >>> > certainly > > >>> > >willing and able to accomodate you. But do you? > > >>> > > > > >>> > >We don't want to complicate the system if no-one will ever > > >>> > need it. I can > > >>> > >construct hypothetical scenarios where cc might be useful > > >>> > even when you > > >>> > >have reserved bandwidth, but I can't think of any=20 > > practical use. > > >>> > > > > >>> > >If your concern is purely that we should not second-guess > > >>> > what people might > > >>> > >want in the future, you need not worry. Because if cc within > > >>> > a resv were > > >>> > >required, a simple extension to the e2e signalling protocol > > >>> > (RSVP or NSIS) > > >>> > >would allow the endpoints to say they wanted to use ECN > > >>> > end-to-end. That > > >>> > >could be added if the need arose. But I don't see the need > > >>> > to add it now. > > >>> > > > > >>> > >" > > >>> > >4.3. Egress gateways > > >>> > > > > >>> > > Egress gateways do the following tasks: > > >>> > > > > >>> > >---snip--- > > >>> > > > > >>> > > o Packet colouring - for CL packets, set the DSCP and > > >>> > the ECN field > > >>> > > to whatever has been agreed as appropriate for the > > >>> > next domain. By > > >>> > > default the ECN field is set to the Not-ECT > > >>> > codepoint. Note that > > >>> > > this results in the loss of the end-to-end=20 > > meaning of the ECN > > >>> > > field. It can usually be assumed that=20 > > end-to-end congestion > > >>> > > control is unnecessary within an end-to-end > > >>> > reservation. But if a > > >>> > > genuine need is identified for end-to-end ECN > > >>> > semantics within a > > >>> > > reservation, then an alternative is to tunnel CL > > >>> > packets across > > >>> > > the CL-region, or to agree an extension to end-to-end > > >>> > signalling > > >>> > > to indicate that the microflow uses an ECN-capable > > >>> > transport. We > > >>> > > do not recommend such apparently unnecessary=20 > complexity. > > >>> > > > > >>> > >" > > >>> > >It's really a question of what everyone believes the default > > >>> > semantics of a > > >>> > >reservation are today: > > >>> > >a) end-to-end cc is not being used for reserved traffic? > > >>> > >b) end-to-end cc is being used for reserved traffic? > > >>> > > > > >>> > >I believe, pragmatically, it is a). > > >>> > > > > >>> > >But perhaps you believe the current default position=20 > > is (b)? If=20 > > >>> > >the consensus of the TSVWG or NSIS w-gs is with you=20 > not me, we > > >>> > would have to > > >>> > >define extensions to RSVP and NSIS for the endpoints to flag > > >>> > that they were > > >>> > >NOT intending to use end-to-end cc. To reduce complexity, I > > >>> > would want the > > >>> > >default for the API to any new signalling stacks to be > > >>> > REQUIRED to be NO > > >>> > >end-to-end congestion control required. > > >>> > > > > >>> > >Then legacy hosts that want to use end-to-end cc would not > > >>> > need to signal > > >>> > >anything new. > > >>> > >And if application writers using reservations said=20 > nothing and=20 > > >>> > >their application was installed on an operating system=20 > > compliant=20 > > >>> > >with the signalling extension it would automatically=20 > > signal that > > >>> > end-to-end cc was > > >>> > >not being used. App writers who wanted to use end-to-end cc=20 > > >>> > >within reservations would have to explicitly call the=20 > > API to say=20 > > >>> > >so. > > >>> > > > > >>> > >Cheers > > >>> > > > > >>> > > > > >>> > > > > >>> > >Bob > > >>> > > > > >>> > >>From: Attila B=E1der (IJ/ETH) > > >>> > >> > > >>> > >>To: "'Bob Briscoe'" > > >>> > >>Cc: "Lars Westberg (KI/EAB)" , > > >>> > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" > > >>> > , > > >>> > >> gqs@jungle.bt.co.uk > > >>> > >>Subject: RE: RE: Meeting to discuss QoS > > >>> > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 > > >>> > >>X-Mailer: Internet Mail Service (5.5.2657.72) > > >>> > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC)=20 > > >>> > >>FILETIME=3D[0F6B35F0:01C48424] > > >>> > >>X-MIME-Autoconverted: from quoted-printable to 8bit by=20 > > >>> > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 > > >>> > >> > > >>> > >>Hi Bob, > > >>> > >> > > >>> > >>Thank you for your answers, I will think of them. > > >>> > > > > >>> > >[BB 10/11/05]: Haven't seen any response since --- until > > >>> > Georgios repeated > > >>> > >the concern in the TSVWG mtg on Tuesday. > > >>> > > > > >>> > >>The work mentioned was not published, so I cannot send a > > >>> > ref. now. The > > >>> > >>contact person knows our investigation, even if not all the=20 > > >>> > >>details, please let me know if you do not get=20 > answer from him. > > >>> > >> > > >>> > >>Best regards, Attila > > >>> > >> > > >>> > >> > -----Original Message----- > > >>> > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > >>> > >> > Sent: Thursday, August 12, 2004 1:54 PM > > >>> > >> > To: Attila B=E1der (IJ/ETH) > > >>> > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl;=20 > > >>> > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk > > >>> > >> > Subject: RE: RE: Meeting to discuss QoS > > >>> > >> > > > >>> > >> > > > >>> > >> > Attila, > > >>> > >> > > > >>> > >> > Sorry for delay - been meeting a submission deadline. > > >>> > See below... > > >>> > >> > > > >>> > >> > At 15:58 06/08/04, IJ/ETH wrote: > > >>> > >> > >Hi Bob, > > >>> > >> > > > > >>> > >> > >I apologize for the late answer, I was very busy=20 > > during the > > >>> > >> > summer and we > > >>> > >> > >had to discuss your proposal. Yesterday we came together > > >>> > >> > with Philip and > > >>> > >> > >Lars for a discussion. > > >>> > >> > > > > >>> > >> > >We have the following main comments regarding the > > >>> > solutions sent us: > > >>> > >> > > > > >>> > >> > >We have also investigated similar solutions. > > >>> > >> > > > >>> > >> > [BB] Refs? > > >>> > >> > > > >>> > >> > >[AB] The main problem we see with ECN marking is=20 > > that it has > > >>> > >> > end-to-end scope. > > >>> > >> > >The default behavior of ECN assumes that the end=20 > > host switch > > >>> > >> > on/off the > > >>> > >> > >marking. > > >>> > >> > > > >>> > >> > [BB] We aren't using the default behaviour. I thought > > >>> > the paper makes this > > >>> > >> > clear. It says we're using all three of the=20 > RSVP, DSCP and=20 > > >>> > >> > ECN /protocols/, but none of their=20 > > /architectures/, that is,=20 > > >>> > >> > we're not using the Intserv, > > >>> > >> > Diffserv, or ECN-TCP architectures. We're just=20 > using ECN at > > >>> > >> > the IP layer. > > >>> > >> > The return path is an opaque object carried by the=20 > > RSVP RESV > > >>> > >> > from edge to > > >>> > >> > edge. > > >>> > >> > > > >>> > >> > Traffic that has had a reservation signalled has=20 > ECT and a=20 > > >>> > >> > guaranteed DSCP turned on at the ingress gateway=20 > > and turned=20 > > >>> > >> > off at the egress. > > >>> > >> > > > >>> > >> > Traffic not under a reservation (either not matching > > >>> > filterspec, or > > >>> > >> > matching but overflowing the token bucket) is policed to=20 > > >>> > >> > ensure it isn't using the guaranteed DSCP. But ECT isn't=20 > > >>> > >> > touched, allowing the end systems > > >>> > >> > to control how congestion is handled. > > >>> > >> > > > >>> > >> > We have various (unresolved) options if ECT is=20 > already on=20 > > >>> > >> > when reserved packets arrive. Obviously we leave=20 > it on at=20 > > >>> > >> > ingress, but the question is > > >>> > >> > how to know not to turn it off at egress. Two=20 > > possibilities: > > >>> > >> > - extend the signalling to say what to do at=20 > > egress (but this > > >>> > >> > doesn't cope > > >>> > >> > with some packets in the reservation having ECT on=20 > > & others off). > > >>> > >> > - tunnel between the gateways (wastes header=20 > space just to > > >>> > >> > tunnel one bit) > > >>> > >> > > > >>> > > > > >>> > >---Snip loads of further conversation--- > > >>> > > > > >>> > > > > >>> > > > > >>> > >_____________________________________________________________ > > >>> > _______________ > > >>> > >Notice: This contribution is the personal view of the author > > >>> > and does not > > >>> > >necessarily reflect the technical nor commercial=20 > > direction of BT=20 > > >>> > >plc.=20 > > >>> > >_____________________________________________________________ > > >>> > _______________ > > >>> > >Bob Briscoe, Networks Research > > >>> > Centre, BT Research > > >>> > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > > >>> > +44 1473 645196 > > >>> > > > > >>> > > > > >>> > > > >> > > >>____________________________________________________________ > > ________________ > > >>Bob Briscoe, Networks Research=20 > Centre, BT=20 > > >>Research > > >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. =20 > > +44 1473=20 > > >>645196 > > >> > > >> > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > >=20 > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 17 08:06:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjSp-0000gs-9n; Thu, 17 Nov 2005 08:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjSn-0000gf-Mw; Thu, 17 Nov 2005 08:06:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21902; Thu, 17 Nov 2005 08:05:30 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcjkQ-0000xY-Gl; Thu, 17 Nov 2005 08:24:19 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id jAHD5gZH028523; Thu, 17 Nov 2005 14:05:46 +0100 (MET) Message-ID: <00a901c5eb77$a327d760$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: , References: <4E28CEA517A795438B120F62D182A8C902540717@I2KM11-UKBR.domain1.systemhost.net> <20051117033507.D9039@openss7.org> Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Date: Thu, 17 Nov 2005 14:05:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: -5.575 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 17 Nov 2005 14:05:52 +0100 (MET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id jAHD5gZH028523 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: philip.eardley@bt.com, tsvwg@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Louise Are you actually indirectly saying that when RSVP is used as an end-to-end QoS signaling protocol for a flow then DCCP must not be used as transport layer protocol for that flow? The previous example shows that there are cases where it is usefull to use both DCCP and RSVP for the same flow! Best regards, Georgios ----- Original Message -----=20 From: "Brian F. G. Bidulock" To: Cc: ; ; ;=20 Sent: Thursday, November 17, 2005 11:35 AM Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between=20 end-to-endECNandedge-to-edge ECN > louise.burness, > > On Thu, 17 Nov 2005, louise.burness@bt.com wrote: > >> If your probability of survival increases with bandwidth, you would >> reserve more > > Maybe not at the expense of someone else's survival. > > Also, I might want to reserve more, but my commanders may have > determined for me that the reservation policy is for the > greater good. > > Why presume that all users are like another: that none can > have any specialized needs or requirements worthy of being > satisfied? Why must a user be mistaken in their motive just > because they are different? > > On the contrary, I think there can exist users that would > benefit from a policy that guarantees a minimum bandwidth > and provides best effort above that minimum. > > --brian > > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 > =A6 Therefore all progress depends on the =A6 > =A6 unreasonable man. -- George Bernard Shaw =A6 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 17 08:28:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecjoc-0007pK-ES; Thu, 17 Nov 2005 08:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcfTj-0003BZ-KF; Thu, 17 Nov 2005 03:50:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07843; Thu, 17 Nov 2005 03:50:14 -0500 (EST) From: louise.burness@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcflK-0000ng-Ig; Thu, 17 Nov 2005 04:08:59 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 08:50:36 +0000 Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 08:50:35 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Date: Thu, 17 Nov 2005 08:50:34 -0000 Message-ID: <4E28CEA517A795438B120F62D182A8C902540713@I2KM11-UKBR.domain1.systemhost.net> Thread-Topic: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Thread-Index: AcXqyG6A/MIdIVuPTgytUDFtvI1o8gAisoWA To: , , , X-OriginalArrivalTime: 17 Nov 2005 08:50:35.0578 (UTC) FILETIME=[F9CE31A0:01C5EB53] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 Nov 2005 08:28:36 -0500 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org If you send more than your reservered amount you have no guarentee on = how the network will treat the excess traffic - but many people might = just drop the excess - or treat it as the lowest of the low (worse than = best effort - higher drop and latency) - so ECN would hardly help then. = Certainly packet re-ordering could also occur giving higher jitter, = because in a general case you process your reservered and BE traffic in = different ways Further, users value stability more than anything else, expts have shown = that users would rather the video run at the lowest (mininum) bandwidth = than fluxuate up and then down - ie lower stable network quality gives a = higher user experianced quality than average higher quality=20 Lou > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org]=20 > On Behalf Of Georgios Karagiannis > Sent: 16 November 2005 16:07 > To: Eardley,PL,Philip,CXR9 R; tsvwg@ietf.org; nsis@ietf.org > Subject: [Tsvwg] Re: [NSIS] interoperability problems between=20 > end-to-endECNandedge-to-edge ECN >=20 >=20 > Hi Phil >=20 > Here is a more concrete example. > Consider that the following streaming application has to be=20 > supported: Video-streaming with rate adaptive coding=20 > application that can adapt the bandwidth but for a feasible=20 > service quality it requires a minimum bandwidth. >=20 > The minimum bandwidth is reserved because otherwise the > service is useless. If the network has more capacity it can=20 > utilize that and give the enduser a higher quality with=20 > better end-user experience. >=20 > This streaming application can very well use ECN and RSVP to=20 > handle the=20 > bandwidth > management. >=20 > Best Regards, > Georgios >=20 >=20 >=20 >=20 > ----- Original Message -----=20 > From: > To: ; ;=20 > ;=20 > > Sent: Wednesday, November 16, 2005 10:58 AM > Subject: RE: [NSIS] interoperability problems between end-to-end=20 > ECNandedge-to-edge ECN >=20 >=20 > > Georgios > > > > Please can you explain the scenario a bit more. I don't=20 > understand it=20 > > yet > > [I think you have a dccp application, using end-to-end ecn=20 > marks, plus an=20 > > edge-to-edge reservation. I guess I don't understand why=20 > someone might be=20 > > doing this] > > > > Thanks > > phil > > > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > On Behalf=20 > > Of > > Georgios Karagiannis > > Sent: 15 November 2005 20:35 > > To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; tsvwg@ietf.org; nsis@ietf.org > > Subject: [NSIS] interoperability problems between end-to-end ECN=20 > > andedge-to-edge ECN > > > > > > Hi Bob > > > > Yes I agree, the admission control based on (pre-)congestion=20 > > notification and the severe congestion (or pre-emption) used in RMD=20 > > and in your proposal are very similar. The main difference of your=20 > > proposal compared to RMD is that the ECN re-marking is used=20 > instead of=20 > > DSCP re-marking. > > > > During the tsvwg meeting, I have tried to emphasize that ECN is=20 > > designed to be an end-to-end concept and not an=20 > edge-to-edge concept.=20 > > When ECN is used for edge-to-edge purposes this might limit the=20 > > current and future applicability of the > > (end-to-end) ECN concept. > > > > > > For example, the current and future applicability of the=20 > DCCP protocol=20 > > might be restricted since streaming applications might not=20 > be able to=20 > > use the complete semantics of the end-to-end ECN concept. > > This problem can become more severe if streaming=20 > applications will be > > using DCCP in combination with a QoS reservation (or a=20 > Diffserv based > > QoS support). Note that this reservation might not go=20 > end-to-end, but > > for example end-to-edge. > > > > > > Best Regards, > > Georgios > > > > On 11/10/2005, "Bob Briscoe" wrote: > > > >>TSVWG & NSIS, > >> > >>It's been pointed out that people on the list don't=20 > understand what my=20 > >>original posting in this thread was about. I was replying=20 > to a point=20 > >>made by Georgios at the mike in TSVWG without giving context. > >> > >>Context > >>------- > >>It is about a difference in approach between RMD (in NSIS) and=20 > >>pre-congestion notification (in TSVWG). Among other=20 > differences, this=20 > >>one is about re-marking on routers within the Diffserv=20 > region if they=20 > >>are congested. > >> > >>In both cases, this re-marked traffic is measured for the aggregate=20 > >>arriving at the egress of the Diffserv region and if above a=20 > >>threshold, admission of new flows to that aggregate is blocked. > >> > >>The difference is that routers in the interior of the region re-mark > >>differently: > >>* RMD re-marks to another Diffserv codepoint and doesn't=20 > touch the ECN=20 > >>field. * Pre-congestion notification re-marks to the CE=20 > codepoint of=20 > >>ECN and doesn't touch the DSCP. > >> > >>One of the reasons RMD didn't touch the ECN codepoint was=20 > so as not to=20 > >>interfere with end-to-end congestion control of the *same* flow. > >> > >>The pre-congestion notification approach deliberately chooses to=20 > >>re-mark the ECN field, on the grounds that it is congestion that is=20 > >>being signalled, albeit 'pre-congestion'. > >> > >>The draft says we think it very unlikely that anyone will be doing=20 > >>end-to-end congestion control as well as reserving capacity for the=20 > >>same flow. But, we say if anyone can give a good reason why=20 > this might=20 > >>happen, we can add mechanism to allow both at once. But we=20 > don't want=20 > >>to add complexity for what seems only a hypothetical requirement. > >> > >>So now, if you're interested, you can go back to the=20 > original posting=20 > >>and perhaps understand the context. > >> > >>Sorry about that. > >> > >>Then, I'd be interested to hear from anyone who can argue for=20 > >>congestion control within a reserved flow. > >> > >> > >> > >> > >>Bob > >> > >>PS. As well as wire protocol differences, there are=20 > important semantic=20 > >>differences in the meaning of a re-marked packet, but we'll=20 > we'll try=20 > >>to reach consensus with the RMD authors on that off-line first then=20 > >>come back to the list with the conclusion. > >> > >> > >> > >>At 18:27 10/11/2005, IJ/ETH wrote: > >>>Hi All, this link may work better, Attila > >>> > >>>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draf > t-westberg > >>>-loadcntr-03.txt > >>> > >>> > -----Original Message----- > >>> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>> > Sent: Thursday, November 10, 2005 6:46 PM > >>> > To: rbriscoe@jungle.bt.co.uk; Attila B=E1der (IJ/ETH) > >>> > Cc: Jozef Babiarz; Kwok-Ho Chan; philip.eardley@bt.com; Lars=20 > >>> > Westberg (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny=20 > >>> > (acharny); tsvwg@ietf.org; nsis@ietf.org > >>> > Subject: Re: RMD & pre-congestion notification: How=20 > edge-edge and=20 > >>> > end-end can interwork > >>> > > >>> > > >>> > > >>> > Hi Bob > >>> > > >>> > Thank you for your e-mail! > >>> > > >>> > Please note that during an IETF meeting in 2000, Lars Westberg=20 > >>> > presented an Internet draft, see bellow, that used the ECN bits=20 > >>> > for edge2edge admission control purposes, but it could=20 > not become=20 > >>> > a WG draft. > >>> > > >>> >=20 > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt > >>> > > >>> > Best Regards, > >>> > Georgios > >>> > > >>> > > >>> > On 11/10/2005, "Bob Briscoe" wrote: > >>> > > >>> > >Attila, Georgios, > >>> > > > >>> > >[cross-posting tsvwg & nsis] > >>> > > > >>> > >Below is the mail I sent to you over a year ago solving your > >>> > concerns over > >>> > >interworking end-end & edge-edge ECN. > >>> > > > >>> > >The similar text below has been in=20 > >>> > > since the initial=20 > >>> > >draft. > >>> > > > >>> > >As it says, if anyone can identify a genuine need to do e2e > >>> > congestion > >>> > >control within a reservation, we have a way to allow it. So > >>> > if you have a > >>> > >plausible reason for why anyone might ever want this, we are > >>> > certainly > >>> > >willing and able to accomodate you. But do you? > >>> > > > >>> > >We don't want to complicate the system if no-one will ever > >>> > need it. I can > >>> > >construct hypothetical scenarios where cc might be useful > >>> > even when you > >>> > >have reserved bandwidth, but I can't think of any=20 > practical use. > >>> > > > >>> > >If your concern is purely that we should not second-guess > >>> > what people might > >>> > >want in the future, you need not worry. Because if cc within > >>> > a resv were > >>> > >required, a simple extension to the e2e signalling protocol > >>> > (RSVP or NSIS) > >>> > >would allow the endpoints to say they wanted to use ECN > >>> > end-to-end. That > >>> > >could be added if the need arose. But I don't see the need > >>> > to add it now. > >>> > > > >>> > >" > >>> > >4.3. Egress gateways > >>> > > > >>> > > Egress gateways do the following tasks: > >>> > > > >>> > >---snip--- > >>> > > > >>> > > o Packet colouring - for CL packets, set the DSCP and > >>> > the ECN field > >>> > > to whatever has been agreed as appropriate for the > >>> > next domain. By > >>> > > default the ECN field is set to the Not-ECT > >>> > codepoint. Note that > >>> > > this results in the loss of the end-to-end=20 > meaning of the ECN > >>> > > field. It can usually be assumed that=20 > end-to-end congestion > >>> > > control is unnecessary within an end-to-end > >>> > reservation. But if a > >>> > > genuine need is identified for end-to-end ECN > >>> > semantics within a > >>> > > reservation, then an alternative is to tunnel CL > >>> > packets across > >>> > > the CL-region, or to agree an extension to end-to-end > >>> > signalling > >>> > > to indicate that the microflow uses an ECN-capable > >>> > transport. We > >>> > > do not recommend such apparently unnecessary complexity. > >>> > > > >>> > >" > >>> > >It's really a question of what everyone believes the default > >>> > semantics of a > >>> > >reservation are today: > >>> > >a) end-to-end cc is not being used for reserved traffic? > >>> > >b) end-to-end cc is being used for reserved traffic? > >>> > > > >>> > >I believe, pragmatically, it is a). > >>> > > > >>> > >But perhaps you believe the current default position=20 > is (b)? If=20 > >>> > >the consensus of the TSVWG or NSIS w-gs is with you not me, we > >>> > would have to > >>> > >define extensions to RSVP and NSIS for the endpoints to flag > >>> > that they were > >>> > >NOT intending to use end-to-end cc. To reduce complexity, I > >>> > would want the > >>> > >default for the API to any new signalling stacks to be > >>> > REQUIRED to be NO > >>> > >end-to-end congestion control required. > >>> > > > >>> > >Then legacy hosts that want to use end-to-end cc would not > >>> > need to signal > >>> > >anything new. > >>> > >And if application writers using reservations said nothing and=20 > >>> > >their application was installed on an operating system=20 > compliant=20 > >>> > >with the signalling extension it would automatically=20 > signal that > >>> > end-to-end cc was > >>> > >not being used. App writers who wanted to use end-to-end cc=20 > >>> > >within reservations would have to explicitly call the=20 > API to say=20 > >>> > >so. > >>> > > > >>> > >Cheers > >>> > > > >>> > > > >>> > > > >>> > >Bob > >>> > > > >>> > >>From: Attila B=E1der (IJ/ETH) > >>> > >> > >>> > >>To: "'Bob Briscoe'" > >>> > >>Cc: "Lars Westberg (KI/EAB)" , > >>> > >> karagian@cs.utwente.nl, "'Philip.Eardley@bt.com'" > >>> > , > >>> > >> gqs@jungle.bt.co.uk > >>> > >>Subject: RE: RE: Meeting to discuss QoS > >>> > >>Date: Tue, 17 Aug 2004 08:33:01 +0200 > >>> > >>X-Mailer: Internet Mail Service (5.5.2657.72) > >>> > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC)=20 > >>> > >>FILETIME=3D[0F6B35F0:01C48424] > >>> > >>X-MIME-Autoconverted: from quoted-printable to 8bit by=20 > >>> > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034 > >>> > >> > >>> > >>Hi Bob, > >>> > >> > >>> > >>Thank you for your answers, I will think of them. > >>> > > > >>> > >[BB 10/11/05]: Haven't seen any response since --- until > >>> > Georgios repeated > >>> > >the concern in the TSVWG mtg on Tuesday. > >>> > > > >>> > >>The work mentioned was not published, so I cannot send a > >>> > ref. now. The > >>> > >>contact person knows our investigation, even if not all the=20 > >>> > >>details, please let me know if you do not get answer from him. > >>> > >> > >>> > >>Best regards, Attila > >>> > >> > >>> > >> > -----Original Message----- > >>> > >> > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > >>> > >> > Sent: Thursday, August 12, 2004 1:54 PM > >>> > >> > To: Attila B=E1der (IJ/ETH) > >>> > >> > Cc: Lars Westberg (KI/EAB); karagian@cs.utwente.nl;=20 > >>> > >> > 'Philip.Eardley@bt.com'; gqs@jungle.bt.co.uk > >>> > >> > Subject: RE: RE: Meeting to discuss QoS > >>> > >> > > >>> > >> > > >>> > >> > Attila, > >>> > >> > > >>> > >> > Sorry for delay - been meeting a submission deadline. > >>> > See below... > >>> > >> > > >>> > >> > At 15:58 06/08/04, IJ/ETH wrote: > >>> > >> > >Hi Bob, > >>> > >> > > > >>> > >> > >I apologize for the late answer, I was very busy=20 > during the > >>> > >> > summer and we > >>> > >> > >had to discuss your proposal. Yesterday we came together > >>> > >> > with Philip and > >>> > >> > >Lars for a discussion. > >>> > >> > > > >>> > >> > >We have the following main comments regarding the > >>> > solutions sent us: > >>> > >> > > > >>> > >> > >We have also investigated similar solutions. > >>> > >> > > >>> > >> > [BB] Refs? > >>> > >> > > >>> > >> > >[AB] The main problem we see with ECN marking is=20 > that it has > >>> > >> > end-to-end scope. > >>> > >> > >The default behavior of ECN assumes that the end=20 > host switch > >>> > >> > on/off the > >>> > >> > >marking. > >>> > >> > > >>> > >> > [BB] We aren't using the default behaviour. I thought > >>> > the paper makes this > >>> > >> > clear. It says we're using all three of the RSVP, DSCP and=20 > >>> > >> > ECN /protocols/, but none of their=20 > /architectures/, that is,=20 > >>> > >> > we're not using the Intserv, > >>> > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at > >>> > >> > the IP layer. > >>> > >> > The return path is an opaque object carried by the=20 > RSVP RESV > >>> > >> > from edge to > >>> > >> > edge. > >>> > >> > > >>> > >> > Traffic that has had a reservation signalled has ECT and a=20 > >>> > >> > guaranteed DSCP turned on at the ingress gateway=20 > and turned=20 > >>> > >> > off at the egress. > >>> > >> > > >>> > >> > Traffic not under a reservation (either not matching > >>> > filterspec, or > >>> > >> > matching but overflowing the token bucket) is policed to=20 > >>> > >> > ensure it isn't using the guaranteed DSCP. But ECT isn't=20 > >>> > >> > touched, allowing the end systems > >>> > >> > to control how congestion is handled. > >>> > >> > > >>> > >> > We have various (unresolved) options if ECT is already on=20 > >>> > >> > when reserved packets arrive. Obviously we leave it on at=20 > >>> > >> > ingress, but the question is > >>> > >> > how to know not to turn it off at egress. Two=20 > possibilities: > >>> > >> > - extend the signalling to say what to do at=20 > egress (but this > >>> > >> > doesn't cope > >>> > >> > with some packets in the reservation having ECT on=20 > & others off). > >>> > >> > - tunnel between the gateways (wastes header space just to > >>> > >> > tunnel one bit) > >>> > >> > > >>> > > > >>> > >---Snip loads of further conversation--- > >>> > > > >>> > > > >>> > > > >>> > >_____________________________________________________________ > >>> > _______________ > >>> > >Notice: This contribution is the personal view of the author > >>> > and does not > >>> > >necessarily reflect the technical nor commercial=20 > direction of BT=20 > >>> > >plc.=20 > >>> > >_____________________________________________________________ > >>> > _______________ > >>> > >Bob Briscoe, Networks Research > >>> > Centre, BT Research > >>> > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > >>> > +44 1473 645196 > >>> > > > >>> > > > >>> > > >> > >>____________________________________________________________ > ________________ > >>Bob Briscoe, Networks Research Centre, BT=20 > >>Research > >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. =20 > +44 1473=20 > >>645196 > >> > >> > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 17 08:28:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecjoc-0007pj-Rm; Thu, 17 Nov 2005 08:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgnZ-0000dE-RM; Thu, 17 Nov 2005 05:15:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11474; Thu, 17 Nov 2005 05:14:48 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[SLVHCcOyxQOVnhpJaVcbuukx2hHzvNWW]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ech5B-0003HF-4M; Thu, 17 Nov 2005 05:33:34 -0500 Received: from ns.pigworks.openss7.net (IDENT:s0+xwNF/kSQcSraQcoLWVrEFBHjqSzzd@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAHAFHA26810; Thu, 17 Nov 2005 03:15:17 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAHAFHg09402; Thu, 17 Nov 2005 03:15:17 -0700 Date: Thu, 17 Nov 2005 03:15:16 -0700 From: "Brian F. G. Bidulock" To: louise.burness@bt.com Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Message-ID: <20051117031516.C9039@openss7.org> References: <4E28CEA517A795438B120F62D182A8C902540713@I2KM11-UKBR.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4E28CEA517A795438B120F62D182A8C902540713@I2KM11-UKBR.domain1.systemhost.net>; from louise.burness@bt.com on Thu, Nov 17, 2005 at 08:50:34AM -0000 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id jAHAFHA26810 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 Nov 2005 08:28:36 -0500 Cc: karagian@cs.utwente.nl, philip.eardley@bt.com, nsis@ietf.org, tsvwg@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org louise.burness, On Thu, 17 Nov 2005, louise.burness@bt.com wrote: > Further, users value stability more than anything else, expts have > shown that users would rather the video run at the lowest (mininum) > bandwidth than fluxuate up and then down - ie lower stable network > quality gives a higher user experianced quality than average higher > quality=20 I wonder how many in the population this sample group is disenfranchising. ;) Best effort over a reserved minimum sounds like a reasonable and valuable bandwidth allocation policy. Users whose probability of survival, or mission success, increases with quality might have a different perspective on the matter than your home users above. --brian --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 17 08:28:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecjod-0007q8-8k; Thu, 17 Nov 2005 08:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecgv4-00059w-QM; Thu, 17 Nov 2005 05:23:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11896; Thu, 17 Nov 2005 05:22:33 -0500 (EST) From: louise.burness@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EchCg-0003XR-9C; Thu, 17 Nov 2005 05:41:19 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 10:22:50 +0000 Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Nov 2005 10:22:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Date: Thu, 17 Nov 2005 10:22:49 -0000 Message-ID: <4E28CEA517A795438B120F62D182A8C902540717@I2KM11-UKBR.domain1.systemhost.net> Thread-Topic: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Thread-Index: AcXrX9N0KdINYicwQHmeNZtNh97dHQAAAKlg To: X-OriginalArrivalTime: 17 Nov 2005 10:22:50.0407 (UTC) FILETIME=[DCD21370:01C5EB60] X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 Nov 2005 08:28:36 -0500 Cc: karagian@cs.utwente.nl, philip.eardley@bt.com, nsis@ietf.org, tsvwg@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org But then the first point - you have no idea what a network will do with packets that from a network perspective are trying to cheat on its reservation by sending too much data. You have no idea which packets of your stream the network will drop as "out of spec". As an operator I suspect we would drop such packets even if there was an totally uncongested best effort buffer. Re-ordering will certainly also occur. If your probability of survival increases with bandwidth, you would reserve more more bandwidth does not equal more quality > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]=20 > Sent: 17 November 2005 10:15 > To: Burness,AL,Louise,CXR9 R > Cc: karagian@cs.utwente.nl; Eardley,PL,Philip,CXR9 R;=20 > tsvwg@ietf.org; nsis@ietf.org > Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems=20 > between end-to-endECNandedge-to-edge ECN >=20 >=20 > louise.burness, >=20 > On Thu, 17 Nov 2005, louise.burness@bt.com wrote: >=20 > > Further, users value stability more than anything else, expts have=20 > > shown that users would rather the video run at the lowest (mininum)=20 > > bandwidth than fluxuate up and then down - ie lower stable network=20 > > quality gives a higher user experianced quality than average higher=20 > > quality >=20 > I wonder how many in the population this sample group is=20 > disenfranchising. ;) >=20 > Best effort over a reserved minimum sounds like a reasonable=20 > and valuable bandwidth allocation policy. Users whose=20 > probability of survival, or mission success, increases with=20 > quality might have a different perspective on the matter than=20 > your home users above. >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock | The reasonable man adapts himself to the | > bidulock@openss7.org | world; the unreasonable one persists in | > http://www.openss7.org/ | trying to adapt the world to himself. | > | Therefore all progress depends on the | > | unreasonable man. -- George Bernard Shaw | >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 17 08:28:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecjod-0007qX-L8; Thu, 17 Nov 2005 08:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ech6p-0000wA-3F; Thu, 17 Nov 2005 05:35:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12479; Thu, 17 Nov 2005 05:34:41 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[ZVyeqeaF275irYE0fkK5J1UdHA87R5Sk]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EchOP-0003yt-OK; Thu, 17 Nov 2005 05:53:28 -0500 Received: from ns.pigworks.openss7.net (IDENT:iMuQz86jLy3Nr7gA1tz0WPNi5GuGnXdT@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAHAZ8A28901; Thu, 17 Nov 2005 03:35:08 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAHAZ7J09610; Thu, 17 Nov 2005 03:35:07 -0700 Date: Thu, 17 Nov 2005 03:35:07 -0700 From: "Brian F. G. Bidulock" To: louise.burness@bt.com Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Message-ID: <20051117033507.D9039@openss7.org> References: <4E28CEA517A795438B120F62D182A8C902540717@I2KM11-UKBR.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4E28CEA517A795438B120F62D182A8C902540717@I2KM11-UKBR.domain1.systemhost.net>; from louise.burness@bt.com on Thu, Nov 17, 2005 at 10:22:49AM -0000 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id jAHAZ8A28901 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 Nov 2005 08:28:36 -0500 Cc: karagian@cs.utwente.nl, philip.eardley@bt.com, nsis@ietf.org, tsvwg@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org louise.burness, On Thu, 17 Nov 2005, louise.burness@bt.com wrote: > If your probability of survival increases with bandwidth, you would > reserve more Maybe not at the expense of someone else's survival. Also, I might want to reserve more, but my commanders may have determined for me that the reservation policy is for the greater good. Why presume that all users are like another: that none can have any specialized needs or requirements worthy of being satisfied? Why must a user be mistaken in their motive just because they are different? On the contrary, I think there can exist users that would benefit from a policy that guarantees a minimum bandwidth and provides best effort above that minimum. --brian --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 17 09:03:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckML-0003BA-OS; Thu, 17 Nov 2005 09:03:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckMK-0003B2-KK for nsis@megatron.ietf.org; Thu, 17 Nov 2005 09:03:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25378 for ; Thu, 17 Nov 2005 09:02:53 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eckdx-0002z0-UX for nsis@ietf.org; Thu, 17 Nov 2005 09:21:43 -0500 Received: from [84.163.20.123] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1EckMD2mO5-0006iw; Thu, 17 Nov 2005 15:03:21 +0100 Received: by alanis.mafr.de (Postfix, from userid 1000) id DE6A55E85EA; Thu, 17 Nov 2005 15:03:15 +0100 (CET) Date: Thu, 17 Nov 2005 15:03:15 +0100 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20051117140315.GA7065@mafr.de> Mail-Followup-To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [NSIS] QSPEC-T: Questions and minor bugs X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I've got some questions about the QSPEC Template. Mostly they are due to minor issues in the spec that should probably be fixed. * What will the version number for the finished standard be? * There is nothing said about how the length field of QSPEC Objects work. I assume they are excluding the header. The length fields of the pre-defined parameters indicate that it's without headers, but it is never said explicitly. * I guess there is no use in empty QSPECs or empty QSPEC Objects. Shouldn't the spec forbid them? * What about duplicate objects or parameters? It seems like it was intended to have unique object types and unique parameter IDs (per object). This is nice and easy to implement because you can store objects or parameters in arrays or hash tables. However, this seems not to be true for the "Reservation Priority" parameter. I'd suggest to make this parameter's length variable and allow multiple (Admission Priority, RPH Namespace, RPH Priority) triples in one parameter. * I'm not sure why parameter IDs have been reassigned. When they were starting with 1, errors were easier to detect. Now 0x00000000 looks like a very broken "Non QOSM Hop" parameter. This is also true for objects. 0x00000000 is a perfectly legal "Control Information" object (unless we prohibit empty objects). In any case: Bandwidth and Slack Term shouldn't have the same ID and the IDs in the Token Bucket section are inconsistent (text vs. diagram). * Section 5.1 is outdated: The QSPEC Procedure Identifier is no longer a parameter. Thanks for reading, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 18 05:01:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed33p-0007in-CT; Fri, 18 Nov 2005 05:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed33m-0007hz-V2; Fri, 18 Nov 2005 05:01:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05579; Fri, 18 Nov 2005 05:01:00 -0500 (EST) From: philip.eardley@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3Lb-0001FG-LW; Fri, 18 Nov 2005 05:20:00 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 10:01:20 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Nov 2005 10:01:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Date: Fri, 18 Nov 2005 10:01:18 -0000 Message-ID: Thread-Topic: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Thread-Index: AcXrd6YUKTMXyjffT+SSTGBt4doy8gAq8vWg To: , , , , , X-OriginalArrivalTime: 18 Nov 2005 10:01:20.0217 (UTC) FILETIME=[06387490:01C5EC27] X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org I don't think I'm any nearer understanding whether there is an example = of why end-to-end ECN is really needed inside a reservation (as opposed = to an idealistic requirement).=20 Rather than spamming tsvwg & nsis I suggest we discuss this further = off-list, and then report back with our conclusion. Is this ok? I think = the cc list is those interested, please say if you want to be added [or = removed].=20 Best wishes Philip Eardley/=20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 17 November 2005 13:06 To: bidulock@openss7.org; Burness,AL,Louise,CXR9 R Cc: Eardley,PL,Philip,CXR9 R; tsvwg@ietf.org; nsis@ietf.org Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between = end-to-endECNandedge-to-edge ECN Hi Louise Are you actually indirectly saying that when RSVP is used as an end-to-end QoS signaling protocol for a flow then DCCP must not be used as transport layer protocol for that flow? The previous example shows that there are cases where it is usefull to use both DCCP and RSVP for the same flow! Best regards, Georgios ----- Original Message -----=20 From: "Brian F. G. Bidulock" To: Cc: ; ; ; = Sent: Thursday, November 17, 2005 11:35 AM Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between=20 end-to-endECNandedge-to-edge ECN > louise.burness, > > On Thu, 17 Nov 2005, louise.burness@bt.com wrote: > >> If your probability of survival increases with bandwidth, you would >> reserve more > > Maybe not at the expense of someone else's survival. > > Also, I might want to reserve more, but my commanders may have > determined for me that the reservation policy is for the > greater good. > > Why presume that all users are like another: that none can > have any specialized needs or requirements worthy of being > satisfied? Why must a user be mistaken in their motive just > because they are different? > > On the contrary, I think there can exist users that would > benefit from a policy that guarantees a minimum bandwidth > and provides best effort above that minimum. > > --brian > > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the = =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in = =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. = =A6 > =A6 Therefore all progress depends on the = =A6 > =A6 unreasonable man. -- George Bernard Shaw = =A6 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 18 08:42:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed6Vy-0004kN-1W; Fri, 18 Nov 2005 08:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecy0g-000216-JU; Thu, 17 Nov 2005 23:38:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20288; Thu, 17 Nov 2005 23:37:28 -0500 (EST) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcyIR-0008LN-G9; Thu, 17 Nov 2005 23:56:24 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id jAI4bpmr059278; Thu, 17 Nov 2005 20:37:52 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200511180437.jAI4bpmr059278@cougar.icir.org> To: "Georgios Karagiannis" From: Sally Floyd Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between end-to-end ECNandedge-to-edge ECN Date: Thu, 17 Nov 2005 20:37:51 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 18 Nov 2005 08:42:52 -0500 Cc: tsvwg@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Just a note about DCCP's use of ECN: DCCP uses ECN by default with both of the currently-defined congestion control mechanisms, CCID2 and CCID3, unless the end-nodes negotiate the connection as being ECN Incapable. The use of ECN Incapable is "NOT RECOMMENDED". From Section 12.1 of draft-ietf-dccp-spec-11.txt: "ECN incapability both avoids ECN's possible benefits and prevents senders from using the ECN Nonce to check for receiver misbehavior. A DCCP stack MAY therefore leave the ECN Incapable feature unimplemented, acting as if all connections were ECN capable." That is, the current ECN Nonce is useful to the sender in checking for receiver misbehavior, in terms of not reporting dropped packets, even in an environment where none of the routers are ECN-capable. This is described in Section 9 of draft-ietf-dccp-ccid3-11.txt. - Sally http://www.icir.org/floyd/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 18 09:17:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed73b-0004vT-Be; Fri, 18 Nov 2005 09:17:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed73a-0004sg-Kb; Fri, 18 Nov 2005 09:17:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20211; Fri, 18 Nov 2005 09:17:03 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed7LR-0001RZ-KB; Fri, 18 Nov 2005 09:36:06 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id jAIEHN3b000473; Fri, 18 Nov 2005 15:17:23 +0100 (MET) Message-ID: <014901c5ec4a$cc888040$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: References: Date: Fri, 18 Nov 2005 15:17:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: -5.282 () ALL_TRUSTED,AWL,BAYES_00,J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 18 Nov 2005 15:17:25 +0100 (MET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id jAIEHN3b000473 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] Re: interoperability problems between end-to-end ECN and edge-to-edge ECN X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Phil Here is some background information regarding the streaming application example! A streaming video application that have "connstant" quality generates bits according to the dynamic in the images: more dynamics (movements of objects) more information. The network may very well be dimensioned for an statistical aggregate rather an absolute peak. Statistical dimensioning is very important in al= l expensive networks and the variable codec can very well congest the network with traffic during peak conditions. However, to be able to ensure a minimum quality level for the end-user, reservation of this may very well be done such that some end-user may be blocked due to limited network capacity. However, we may want to ensure that the codec adapts to the available bitrate instead of experiencing a lot of packet losses. The network scenario is therefore as following: * Minimum reserved capacity to ensure a sufficient end-user experience. * Allow a common network resource shared among the end-users in the network * Using ECN as a feedback to the speech codec when the network starting to be fully loaded. * Block new end-user when the minum bandwidth can not be fulfilled. Hopefully, the above information helps! Best regards, Georgios ----- Original Message -----=20 From: To: ; ;=20 ; ; ;=20 Cc: ; Sent: Friday, November 18, 2005 11:01 AM Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems between=20 end-to-endECNandedge-to-edge ECN >I don't think I'm any nearer understanding whether there is an example o= f=20 >why end-to-end ECN is really needed inside a reservation (as opposed to = an=20 >idealistic requirement). > Rather than spamming tsvwg & nsis I suggest we discuss this further=20 > off-list, and then report back with our conclusion. Is this ok? I think= =20 > the cc list is those interested, please say if you want to be added [or= =20 > removed]. > > Best wishes > Philip Eardley/ > > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 17 November 2005 13:06 > To: bidulock@openss7.org; Burness,AL,Louise,CXR9 R > Cc: Eardley,PL,Philip,CXR9 R; tsvwg@ietf.org; nsis@ietf.org > Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between=20 > end-to-endECNandedge-to-edge ECN > > Hi Louise > > Are you actually indirectly saying that when RSVP is used as an > end-to-end QoS signaling protocol for a flow then DCCP must not be used > as transport layer protocol for that flow? > > The previous example shows that there are cases where it is usefull to > use both DCCP and RSVP for the same flow! > > Best regards, > Georgios > > > > ----- Original Message -----=20 > From: "Brian F. G. Bidulock" > To: > Cc: ; ; = ; > > Sent: Thursday, November 17, 2005 11:35 AM > Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between > end-to-endECNandedge-to-edge ECN > > >> louise.burness, >> >> On Thu, 17 Nov 2005, louise.burness@bt.com wrote: >> >>> If your probability of survival increases with bandwidth, you would >>> reserve more >> >> Maybe not at the expense of someone else's survival. >> >> Also, I might want to reserve more, but my commanders may have >> determined for me that the reservation policy is for the >> greater good. >> >> Why presume that all users are like another: that none can >> have any specialized needs or requirements worthy of being >> satisfied? Why must a user be mistaken in their motive just >> because they are different? >> >> On the contrary, I think there can exist users that would >> benefit from a policy that guarantees a minimum bandwidth >> and provides best effort above that minimum. >> >> --brian >> >> --=20 >> Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 >> bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 >> http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 >> =A6 Therefore all progress depends on the =A6 >> =A6 unreasonable man. -- George Bernard Shaw =A6 >> > >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 18 17:14:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEVG-00014q-NZ; Fri, 18 Nov 2005 17:14:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEVE-00014A-LM for nsis@megatron.ietf.org; Fri, 18 Nov 2005 17:14:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13919 for ; Fri, 18 Nov 2005 17:14:04 -0500 (EST) Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdEn9-0005WF-SY for nsis@ietf.org; Fri, 18 Nov 2005 17:33:12 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 22:14:29 +0000 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 22:14:30 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 22:14:28 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1132352067734; Fri, 18 Nov 2005 22:14:27 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.7]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id jAIMELDt019659; Fri, 18 Nov 2005 22:14:26 GMT Message-Id: <5.2.1.1.2.20051118190810.040c5f78@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 18 Nov 2005 22:14:27 +0000 To: Sally Floyd , "Georgios Karagiannis" , Attila =?iso-8859-1?Q?B=E1der?= (IJ/ETH) From: Bob Briscoe In-Reply-To: <200511180521.jAI5LV5E059944@cougar.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Nov 2005 22:14:28.0843 (UTC) FILETIME=[717C1BB0:01C5EC8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios, Attila, To be concrete, I'll ask the question I started with again. Why don't the changes to RSVP and NSIS (that I repeat below) resolve the conflict between end-to-end and edge-to-edge semantics? The conflict only occurs for flows within a signalled reservation, so the conflict can be resolved in the signalling. If the conflict is resolved, this proposal should satisfy Sally's requirements for specifying alternate semantics for ECN in an edge-edge scenario. [Sally, I'd also be interested in your view - general rules are fine, but particular cases like this test the wording.] I started the earlier thread with this proposal, but as so often happens, the very first reply didn't answer the question, then everyone who joined the thread continued to "lose the thread". The archived posting is at: ---start repeated text--- It's really a question of what everyone believes the default semantics of a reservation are today: a) end-to-end cc is not being used for reserved traffic? b) end-to-end cc is being used for reserved traffic? I believe, pragmatically, it is a). But perhaps you believe the current default position is (b)? If the consensus of the TSVWG or NSIS w-gs is with you not me, we would have to define extensions to RSVP and NSIS for the endpoints to flag that they were NOT intending to use end-to-end cc. To reduce complexity, I would want the default for the API to any new signalling stacks to be REQUIRED to be NO end-to-end congestion control required. Then legacy hosts that want to use end-to-end cc would not need to signal anything new. And if application writers using reservations said nothing and their application was installed on an operating system compliant with the signalling extension it would automatically signal that end-to-end cc was not being used. App writers who wanted to use end-to-end cc within reservations would have to explicitly call the API to say so. ---end repeated text--- As I also said in the original posting (and we said in our draft), it's only worth making this change to RSVP (and NSIS) if there is any hope of it ever being necessary. That discussion is still continuing on the lists. Bob At 05:21 18/11/2005, Sally Floyd wrote: >Georgios - > > >In my opinion, the draft-floyd-ecn-alternates-02.txt could emphasize > >which are the requirements that the > >edge-to-edge ECN semantics should fulfill such that the > >current and future applicability of the (end-to-end) ECN concept > >is not limited. > >I agree. > >My proposal would be to add the following section to >draft-floyd-ecn-alternates-02.txt: > > "Proposals for Alternate-ECN with Edge-to-Edge Semantics" > > RFC 3168 specifies the use of the default ECN semantics by an > end-to-end transport protocol, with the requirement that "upon the > receipt by an ECN-Capable transport of a single CE packet, the > congestion control algorithms followed at the end-systems MUST be > essentially the same as the congestion control response to a *single* > dropped packet" [RFC3168, Section 5]. In contrast, some of the > proposals for alternate-ECN semantics are for ECN used in an > edge-to-edge context between gateways at the edge of a network > region, e.g., for pre-congestion notification for admissions control > [BESFC05]. > > When alternate-ECN is defined with edge-to-edge semantics, this > definition needs to ensure that the edge-to-edge semanatics do not > conflict with a connection using other ECN semantics end-to-end. > One way to avoid conflict would be for the edge-to-edge ECN proposal > to include some mechanism to ensure that the edge-to-edge ECN is > not used for connections that are using other ECN semantics (standard > or otherwise) end-to-end. Alternately, the edge-to-edge semantics > could be defined so that they do not conflict with a connection > using other ECN semantics end-to-end. > >Feedback would be welcome. > >- Sally >http://www.icir.org/floyd/ > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Nov 19 07:40:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdS1F-0001bv-N4; Sat, 19 Nov 2005 07:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdS1D-0001bO-6e; Sat, 19 Nov 2005 07:40:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25776; Sat, 19 Nov 2005 07:39:59 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdSJF-0000ux-Th; Sat, 19 Nov 2005 07:59:14 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id jAJCe8HW012478; Sat, 19 Nov 2005 13:40:08 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id jAJCdv5B027885; Sat, 19 Nov 2005 13:39:57 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id jAJCdvF29581; Sat, 19 Nov 2005 13:39:57 +0100 (MET) Date: Sat, 19 Nov 2005 13:39:57 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: rbriscoe@jungle.bt.co.uk, floyd@icir.org, attila.bader@ericsson.com Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 19 Nov 2005 12:39:57 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <5.2.1.1.2.20051118190810.040c5f78@pop3.jungle.bt.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.249 () ALL_TRUSTED, AWL, BAYES_00, J_CHICKENPOX_57, MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 19 Nov 2005 13:40:20 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: "tsvwg@ietf.org" , "nsis@ietf.org" Subject: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Bob The streaming aplication example that has been discussed in the tsvwg and nsis mailing lists shows that it is usefull to use end-to-end ECN based congestion control for reserved traffic. This streaming application example can very efficiently use RSVP and the DCCP protocol (which uses the end-to-end ECN concept). One can think of situations (applications) where it is not needed to use end-to-end cc for reserved traffic. Thus I would say that a third option should be available in the selection process: c) the ability of using end-to-end ECN based congestion control for reserved traffic should be possible. Meaning that for some applications you may use end-to-end ECN based congestion control for reserved traffic and for other applications you may not use end-to-end ECN based congestion control for reserved traffic. Regarding your following proposal: >To reduce complexity, I would want the >default for the API to any new signalling stacks to be REQUIRED to be NO >end-to-end congestion control required. Are you actually indirectly saying that whenever the IETF standardizes a new signaling protocol this protocol MUST not be used in combination with the DCCP protocol (which actually uses the end-to-end ECN concept)? Best Regards, Georgios On 11/18/2005, "Bob Briscoe" wrote: >Georgios, Attila, > >To be concrete, I'll ask the question I started with again. Why don't the >changes to RSVP and NSIS (that I repeat below) resolve the conflict between >end-to-end and edge-to-edge semantics? The conflict only occurs for flows >within a signalled reservation, so the conflict can be resolved in the >signalling. If the conflict is resolved, this proposal should satisfy >Sally's requirements for specifying alternate semantics for ECN in an >edge-edge scenario. > >[Sally, I'd also be interested in your view - general rules are fine, but >particular cases like this test the wording.] > >I started the earlier thread with this proposal, but as so often happens, >the very first reply didn't answer the question, then everyone who joined >the thread continued to "lose the thread". The archived posting is at: > > >---start repeated text--- > >It's really a question of what everyone believes the default semantics of a >reservation are today: >a) end-to-end cc is not being used for reserved traffic? >b) end-to-end cc is being used for reserved traffic? > >I believe, pragmatically, it is a). > >But perhaps you believe the current default position is (b)? If the >consensus of the TSVWG or NSIS w-gs is with you not me, we would have to >define extensions to RSVP and NSIS for the endpoints to flag that they were >NOT intending to use end-to-end cc. To reduce complexity, I would want the >default for the API to any new signalling stacks to be REQUIRED to be NO >end-to-end congestion control required. > >Then legacy hosts that want to use end-to-end cc would not need to signal >anything new. >And if application writers using reservations said nothing and their >application was installed on an operating system compliant with the >signalling extension it would automatically signal that end-to-end cc was >not being used. App writers who wanted to use end-to-end cc within >reservations would have to explicitly call the API to say so. >---end repeated text--- > >As I also said in the original posting (and we said in our draft), it's >only worth making this change to RSVP (and NSIS) if there is any hope of it >ever being necessary. That discussion is still continuing on the lists. > > >Bob > >At 05:21 18/11/2005, Sally Floyd wrote: >>Georgios - >> >> >In my opinion, the draft-floyd-ecn-alternates-02.txt could emphasize >> >which are the requirements that the >> >edge-to-edge ECN semantics should fulfill such that the >> >current and future applicability of the (end-to-end) ECN concept >> >is not limited. >> >>I agree. >> >>My proposal would be to add the following section to >>draft-floyd-ecn-alternates-02.txt: >> >> "Proposals for Alternate-ECN with Edge-to-Edge Semantics" >> >> RFC 3168 specifies the use of the default ECN semantics by an >> end-to-end transport protocol, with the requirement that "upon the >> receipt by an ECN-Capable transport of a single CE packet, the >> congestion control algorithms followed at the end-systems MUST be >> essentially the same as the congestion control response to a *single* >> dropped packet" [RFC3168, Section 5]. In contrast, some of the >> proposals for alternate-ECN semantics are for ECN used in an >> edge-to-edge context between gateways at the edge of a network >> region, e.g., for pre-congestion notification for admissions control >> [BESFC05]. >> >> When alternate-ECN is defined with edge-to-edge semantics, this >> definition needs to ensure that the edge-to-edge semanatics do not >> conflict with a connection using other ECN semantics end-to-end. >> One way to avoid conflict would be for the edge-to-edge ECN proposal >> to include some mechanism to ensure that the edge-to-edge ECN is >> not used for connections that are using other ECN semantics (standard >> or otherwise) end-to-end. Alternately, the edge-to-edge semantics >> could be defined so that they do not conflict with a connection >> using other ECN semantics end-to-end. >> >>Feedback would be welcome. >> >>- Sally >>http://www.icir.org/floyd/ >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg > >____________________________________________________________________________ >Notice: This contribution is the personal view of the author and does not >necessarily reflect the technical nor commercial direction of BT plc. >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Nov 20 11:44:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdsIL-0004t0-FD; Sun, 20 Nov 2005 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed7Aa-00006v-PK; Fri, 18 Nov 2005 09:24:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20477; Fri, 18 Nov 2005 09:24:16 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed7SQ-0001cy-H7; Fri, 18 Nov 2005 09:43:20 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAIEOCr24501; Fri, 18 Nov 2005 09:24:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems betweenend-to-endECNandedge-to-edge ECN Date: Fri, 18 Nov 2005 09:23:52 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465070A878A@zcarhxm1.corp.nortel.com> Thread-Topic: [Tsvwg] Re: [NSIS] interoperability problems betweenend-to-endECNandedge-to-edge ECN Thread-Index: AcXrd6YUKTMXyjffT+SSTGBt4doy8gAq8vWgAAoJ7DA= From: "Jozef Babiarz" To: , , , , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 20 Nov 2005 11:44:00 -0500 Cc: tsvwg@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Phil, Please add me to the discussion list. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Friday, November 18, 2005 5:01 AM To: karagian@cs.utwente.nl; bidulock@openss7.org; louise.burness@bt.com; bob.briscoe@bt.com; attila.bader@ericsson.com; floyd@icir.org Cc: tsvwg@ietf.org; nsis@ietf.org Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems betweenend-to-endECNandedge-to-edge ECN I don't think I'm any nearer understanding whether there is an example of why end-to-end ECN is really needed inside a reservation (as opposed to an idealistic requirement).=20 Rather than spamming tsvwg & nsis I suggest we discuss this further off-list, and then report back with our conclusion. Is this ok? I think the cc list is those interested, please say if you want to be added [or removed].=20 Best wishes Philip Eardley/=20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 17 November 2005 13:06 To: bidulock@openss7.org; Burness,AL,Louise,CXR9 R Cc: Eardley,PL,Philip,CXR9 R; tsvwg@ietf.org; nsis@ietf.org Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN Hi Louise Are you actually indirectly saying that when RSVP is used as an end-to-end QoS signaling protocol for a flow then DCCP must not be used as transport layer protocol for that flow? The previous example shows that there are cases where it is usefull to use both DCCP and RSVP for the same flow! Best regards, Georgios ----- Original Message -----=20 From: "Brian F. G. Bidulock" To: Cc: ; ; ; Sent: Thursday, November 17, 2005 11:35 AM Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between=20 end-to-endECNandedge-to-edge ECN > louise.burness, > > On Thu, 17 Nov 2005, louise.burness@bt.com wrote: > >> If your probability of survival increases with bandwidth, you would >> reserve more > > Maybe not at the expense of someone else's survival. > > Also, I might want to reserve more, but my commanders may have > determined for me that the reservation policy is for the > greater good. > > Why presume that all users are like another: that none can > have any specialized needs or requirements worthy of being > satisfied? Why must a user be mistaken in their motive just > because they are different? > > On the contrary, I think there can exist users that would > benefit from a policy that guarantees a minimum bandwidth > and provides best effort above that minimum. > > --brian > > --=20 > Brian F. G. Bidulock | The reasonable man adapts himself to the | > bidulock@openss7.org | world; the unreasonable one persists in | > http://www.openss7.org/ | trying to adapt the world to himself. | > | Therefore all progress depends on the | > | unreasonable man. -- George Bernard Shaw | >=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Nov 20 11:44:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdsIL-0004tP-R7; Sun, 20 Nov 2005 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed7Qi-0003Qt-Ja; Fri, 18 Nov 2005 09:41:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21331; Fri, 18 Nov 2005 09:40:56 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed7iY-00028Z-Sd; Fri, 18 Nov 2005 10:00:00 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAIEf0C04277; Fri, 18 Nov 2005 09:41:00 -0500 (EST) Received: from KCHAN-2K3.nortel.com ([47.16.54.138] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 09:41:00 -0500 Message-Id: <6.2.5.6.0.20051118093913.03cffae0@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 18 Nov 2005 09:40:59 -0500 To: philip.eardley@bt.com From: "Kwok-Ho Chan" Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 18 Nov 2005 14:41:00.0430 (UTC) FILETIME=[1801C2E0:01C5EC4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 20 Nov 2005 11:44:00 -0500 Cc: karagian@cs.utwente.nl, floyd@icir.org, nsis@ietf.org, attila.bader@ericsson.com, louise.burness@bt.com, bidulock@openss7.org, tsvwg@ietf.org, bob.briscoe@bt.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Phil: If this discussion is off TSVWG or NSIS list, please add me to the cc list. Thanks! -- Kwok -- At 05:01 AM 11/18/2005, philip.eardley@bt.com wrote: >I don't think I'm any nearer understanding=20 >whether there is an example of why end-to-end=20 >ECN is really needed inside a reservation (as=20 >opposed to an idealistic requirement). >Rather than spamming tsvwg & nsis I suggest we=20 >discuss this further off-list, and then report=20 >back with our conclusion. Is this ok? I think=20 >the cc list is those interested, please say if=20 >you want to be added [or removed]. > >Best wishes >Philip Eardley/ > >-----Original Message----- >From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >Sent: 17 November 2005 13:06 >To: bidulock@openss7.org; Burness,AL,Louise,CXR9 R >Cc: Eardley,PL,Philip,CXR9 R; tsvwg@ietf.org; nsis@ietf.org >Subject: Re: [Tsvwg] Re: [NSIS] interoperability=20 >problems between end-to-endECNandedge-to-edge ECN > >Hi Louise > >Are you actually indirectly saying that when RSVP is used as an >end-to-end QoS signaling protocol for a flow then DCCP must not be used >as transport layer protocol for that flow? > >The previous example shows that there are cases where it is usefull to >use both DCCP and RSVP for the same flow! > >Best regards, >Georgios > > > >----- Original Message ----- >From: "Brian F. G. Bidulock" >To: >Cc: ; ; ; > >Sent: Thursday, November 17, 2005 11:35 AM >Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between >end-to-endECNandedge-to-edge ECN > > > > louise.burness, > > > > On Thu, 17 Nov 2005, louise.burness@bt.com wrote: > > > >> If your probability of survival increases with bandwidth, you would > >> reserve more > > > > Maybe not at the expense of someone else's survival. > > > > Also, I might want to reserve more, but my commanders may have > > determined for me that the reservation policy is for the > > greater good. > > > > Why presume that all users are like another: that none can > > have any specialized needs or requirements worthy of being > > satisfied? Why must a user be mistaken in their motive just > > because they are different? > > > > On the contrary, I think there can exist users that would > > benefit from a policy that guarantees a minimum bandwidth > > and provides best effort above that minimum. > > > > --brian > > > > -- > > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 > > bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 > > http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 > > =A6 Therefore all progress depends on the =A6 > > =A6 unreasonable man. -- George Bernard Shaw =A6 > > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 21 04:52:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee8Lz-0002H2-Dk; Mon, 21 Nov 2005 04:52:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee8Ly-0002Gr-1c; Mon, 21 Nov 2005 04:52:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17377; Mon, 21 Nov 2005 04:52:12 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee8eM-0005QD-8k; Mon, 21 Nov 2005 05:11:53 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id jAL9qRPF002523; Mon, 21 Nov 2005 10:52:31 +0100 (MET) Message-ID: <008501c5ee81$4a950840$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: References: Date: Mon, 21 Nov 2005 10:52:22 +0100 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: -5.23 () ALL_TRUSTED, AWL, BAYES_00, FVGT_u_HAS_2LETTERFLDR, J_CHICKENPOX_57 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 21 Nov 2005 10:52:34 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] why use edge-to-edge ECN re-marking when DSCP re-marking can do it X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Bob In addition to the previous discussion I would like to discuss and ask you the following. As you already mentioned the admission control based on congestion notification and severe congestion [pre-emption] described in RMD, (see http://www.watersprings.org/pub/id/draft-ietf-nsis-rmd-04.txt), and in your proposal are very similar (almost identical), in terms of protocol semantics. The main difference is related to the fact that RMD uses DSCP re-marking while you are willing to apply ECN re-marking (in an edge-to-edge ECN scenario). >From the previous discussions we have seen that there are interoperability problems between the end-to-end ECN semantics and edge-to-edge ECN semantics. The DSCP re-marking does not generate such interoperability problems. Thus my question is: What is the technical reason of using ECN for edge-toedge congestion control, when the same solution (on providing admission control based on congestion notification and severe congestion [pre-emption]) can be provided by using DSCP re-marking? Best regards, Georgios ----- Original Message ----- From: "Georgios Karagiannis" To: ; ; Cc: ; Sent: Saturday, November 19, 2005 1:39 PM Subject: Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt > > Hi Bob > > The streaming aplication example that has been discussed in > the tsvwg and nsis mailing lists shows that it is usefull to use > end-to-end ECN based congestion control for reserved traffic. > This streaming application example can very efficiently use RSVP and the > DCCP protocol (which uses the end-to-end ECN concept). > > One can think of situations (applications) where it is not needed to use > end-to-end cc for reserved traffic. Thus I would say that a third option > should be available in the selection process: > c) the ability of using end-to-end ECN based congestion control for > reserved traffic should be possible. Meaning that for some applications > you may use end-to-end ECN based congestion control for reserved traffic > and for other applications you may not use end-to-end ECN based > congestion control for reserved traffic. > > Regarding your following proposal: >>To reduce complexity, I would want the >>default for the API to any new signalling stacks to be REQUIRED to be NO >>end-to-end congestion control required. > > Are you actually indirectly saying that whenever the IETF standardizes a > new signaling protocol this protocol MUST not be used in combination > with the DCCP protocol (which actually uses the end-to-end ECN concept)? > > > Best Regards, > Georgios > > > On 11/18/2005, "Bob Briscoe" wrote: > >>Georgios, Attila, >> >>To be concrete, I'll ask the question I started with again. Why don't the >>changes to RSVP and NSIS (that I repeat below) resolve the conflict >>between >>end-to-end and edge-to-edge semantics? The conflict only occurs for flows >>within a signalled reservation, so the conflict can be resolved in the >>signalling. If the conflict is resolved, this proposal should satisfy >>Sally's requirements for specifying alternate semantics for ECN in an >>edge-edge scenario. >> >>[Sally, I'd also be interested in your view - general rules are fine, but >>particular cases like this test the wording.] >> >>I started the earlier thread with this proposal, but as so often happens, >>the very first reply didn't answer the question, then everyone who joined >>the thread continued to "lose the thread". The archived posting is at: >> >> >>---start repeated text--- >> >>It's really a question of what everyone believes the default semantics of >>a >>reservation are today: >>a) end-to-end cc is not being used for reserved traffic? >>b) end-to-end cc is being used for reserved traffic? >> >>I believe, pragmatically, it is a). >> >>But perhaps you believe the current default position is (b)? If the >>consensus of the TSVWG or NSIS w-gs is with you not me, we would have to >>define extensions to RSVP and NSIS for the endpoints to flag that they >>were >>NOT intending to use end-to-end cc. To reduce complexity, I would want the >>default for the API to any new signalling stacks to be REQUIRED to be NO >>end-to-end congestion control required. >> >>Then legacy hosts that want to use end-to-end cc would not need to signal >>anything new. >>And if application writers using reservations said nothing and their >>application was installed on an operating system compliant with the >>signalling extension it would automatically signal that end-to-end cc was >>not being used. App writers who wanted to use end-to-end cc within >>reservations would have to explicitly call the API to say so. >>---end repeated text--- >> >>As I also said in the original posting (and we said in our draft), it's >>only worth making this change to RSVP (and NSIS) if there is any hope of >>it >>ever being necessary. That discussion is still continuing on the lists. >> >> >>Bob >> >>At 05:21 18/11/2005, Sally Floyd wrote: >>>Georgios - >>> >>> >In my opinion, the draft-floyd-ecn-alternates-02.txt could emphasize >>> >which are the requirements that the >>> >edge-to-edge ECN semantics should fulfill such that the >>> >current and future applicability of the (end-to-end) ECN concept >>> >is not limited. >>> >>>I agree. >>> >>>My proposal would be to add the following section to >>>draft-floyd-ecn-alternates-02.txt: >>> >>> "Proposals for Alternate-ECN with Edge-to-Edge Semantics" >>> >>> RFC 3168 specifies the use of the default ECN semantics by an >>> end-to-end transport protocol, with the requirement that "upon the >>> receipt by an ECN-Capable transport of a single CE packet, the >>> congestion control algorithms followed at the end-systems MUST be >>> essentially the same as the congestion control response to a *single* >>> dropped packet" [RFC3168, Section 5]. In contrast, some of the >>> proposals for alternate-ECN semantics are for ECN used in an >>> edge-to-edge context between gateways at the edge of a network >>> region, e.g., for pre-congestion notification for admissions control >>> [BESFC05]. >>> >>> When alternate-ECN is defined with edge-to-edge semantics, this >>> definition needs to ensure that the edge-to-edge semanatics do not >>> conflict with a connection using other ECN semantics end-to-end. >>> One way to avoid conflict would be for the edge-to-edge ECN proposal >>> to include some mechanism to ensure that the edge-to-edge ECN is >>> not used for connections that are using other ECN semantics (standard >>> or otherwise) end-to-end. Alternately, the edge-to-edge semantics >>> could be defined so that they do not conflict with a connection >>> using other ECN semantics end-to-end. >>> >>>Feedback would be welcome. >>> >>>- Sally >>>http://www.icir.org/floyd/ >>> >>>_______________________________________________ >>>tsvwg mailing list >>>tsvwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/tsvwg >> >>____________________________________________________________________________ >>Notice: This contribution is the personal view of the author and does not >>necessarily reflect the technical nor commercial direction of BT plc. >>____________________________________________________________________________ >>Bob Briscoe, Networks Research Centre, BT >>Research >>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 >>645196 >> > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Nov 22 03:56:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeTwe-0005qz-Jz; Tue, 22 Nov 2005 03:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeTwc-0005qk-Qc for nsis@megatron.ietf.org; Tue, 22 Nov 2005 03:56:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19033 for ; Tue, 22 Nov 2005 03:55:29 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeUFC-0006xH-JL for nsis@ietf.org; Tue, 22 Nov 2005 04:15:21 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id jAM8tuBQ017097; Tue, 22 Nov 2005 09:55:56 +0100 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id jAM8tssC014934; Tue, 22 Nov 2005 09:55:55 +0100 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 09:55:54 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] QSPEC-T: Questions and minor bugs Date: Tue, 22 Nov 2005 09:55:53 +0100 Message-ID: <391E6FBF5E786940B9E2F7CA6376C708DE4592@blns00fa.ww002.siemens.net> Thread-Topic: [NSIS] QSPEC-T: Questions and minor bugs Thread-Index: AcXrgQt7/9HY6rSlRGawjMhp3KpV8wDwAI+A From: "Kappler, Cornelia" To: "Matthias Friedrich" , X-OriginalArrivalTime: 22 Nov 2005 08:55:54.0652 (UTC) FILETIME=[8C0DC5C0:01C5EF42] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Attila Bader \(ETH\)" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Matthias, Thanks a lot for your careful reading, and for your comments and suggestions. > I've got some questions about the QSPEC Template. Mostly they are due > to minor issues in the spec that should probably be fixed. >=20 > * What will the version number for the finished standard be? As stated in Section 9 (IANA Considerations) in http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt: "QSPEC Version (4 bits): The following value is allocated by this specification: 0: assigned to Version 0 QSPEC" =20 > * There is nothing said about how the length field of QSPEC Objects > work. I assume they are excluding the header. The length fields of > the pre-defined parameters indicate that it's without headers, but > it is never said explicitly. Yes, the Object length excludes the header. We'll clarify that in the next revision. =20 > * I guess there is no use in empty QSPECs or empty QSPEC Objects. > Shouldn't the spec forbid them? OK, we'll state that in the next revision. =20 > * What about duplicate objects or parameters? It seems like it was > intended to have unique object types and unique parameter IDs (per > object). This is nice and easy to implement because you can store > objects or parameters in arrays or hash tables. > However, this seems not to be true for the "Reservation Priority" > parameter. I'd suggest to make this parameter's length variable and > allow multiple (Admission Priority, RPH Namespace, RPH Priority) > triples in one parameter. It is true that multiple occurrences of a parameter are not possible. We clarify in the next version.=20 Good point about Reservation Priority. Other approaches to fix this: 1. Keep the parameter as is, with fixed length. Require that if Admission Priority =3D 0 (high), then MUST set RPH Namespace =3D 5 (not populated) and RPH Priority =3D don't care (any) 2. Make Admission Priority and RPH Namespace/RPH Priority separate QSPEC parameters with fixed lengths. I like approach #1, it is already implicitly specified, just needs to be explicit. =20 > * I'm not sure why parameter IDs have been reassigned. When they were > starting with 1, errors were easier to detect. Now 0x00000000 looks > like a very broken "Non QOSM Hop" parameter. > This is also true for objects. 0x00000000 is a perfectly legal > "Control Information" object (unless we prohibit empty objects). We can start numbering parameters/objects with 1 if that prevents errors. However we dont understand why starting with 0 is a problem? =20 > In any case: Bandwidth and Slack Term shouldn't have the same ID and > the IDs in the Token Bucket section are inconsistent (text=20 > vs. diagram). Right, we'll correct that. =20 > * Section 5.1 is outdated: The QSPEC Procedure Identifier is no longer > a parameter. Right, we'll correct that. Thanks again, Regards, Jerry, Cornelia, Attila=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Nov 22 16:52:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeg3d-0003RG-Dk; Tue, 22 Nov 2005 16:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeg3c-0003RB-M4 for nsis@megatron.ietf.org; Tue, 22 Nov 2005 16:52:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17166 for ; Tue, 22 Nov 2005 16:51:30 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EegMM-00072P-7E for nsis@ietf.org; Tue, 22 Nov 2005 17:11:30 -0500 Received: from [84.163.33.144] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2Dk-1Eeg3W0pQw-0000W5; Tue, 22 Nov 2005 22:52:02 +0100 Received: by alanis.mafr.de (Postfix, from userid 1000) id 100B75E82D2; Tue, 22 Nov 2005 22:51:06 +0100 (CET) Date: Tue, 22 Nov 2005 22:51:06 +0100 From: Matthias Friedrich To: "Kappler, Cornelia" Subject: Re: [NSIS] QSPEC-T: Questions and minor bugs Message-ID: <20051122215106.GA11263@mafr.de> Mail-Followup-To: "Kappler, Cornelia" , nsis@ietf.org, "Ash, Gerald R (Jerry), ALABS" , "Attila Bader (ETH)" References: <391E6FBF5E786940B9E2F7CA6376C708DE4592@blns00fa.ww002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <391E6FBF5E786940B9E2F7CA6376C708DE4592@blns00fa.ww002.siemens.net> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org, "Attila Bader \(ETH\)" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, On Tuesday, 2005-11-22, Kappler, Cornelia wrote: [...] >> * What will the version number for the finished standard be? > As stated in Section 9 (IANA Considerations) in > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-07.txt: > "QSPEC Version (4 bits): > The following value is allocated by this specification: > 0: assigned to Version 0 QSPEC" So the finished standard will have 0, too, ok. [...] > Good point about Reservation Priority. Other approaches to fix this: > 1. Keep the parameter as is, with fixed length. Require that if > Admission Priority = 0 (high), then MUST set RPH Namespace = 5 (not > populated) and RPH Priority = don't care (any) > 2. Make Admission Priority and RPH Namespace/RPH Priority separate QSPEC > parameters with fixed lengths. > I like approach #1, it is already implicitly specified, just needs to be > explicit. I don't mind, as long as parameter IDs inside objects are unique. >> * I'm not sure why parameter IDs have been reassigned. When they were >> starting with 1, errors were easier to detect. Now 0x00000000 looks >> like a very broken "Non QOSM Hop" parameter. >> This is also true for objects. 0x00000000 is a perfectly legal >> "Control Information" object (unless we prohibit empty objects). > We can start numbering parameters/objects with 1 if that prevents > errors. However we dont understand why starting with 0 is a problem? It is no problem, it just made a bug in my code more difficult to find. There's really no need to change things because of my mistakes, I was just interested if there was a special reason :-) The library I use works with fixed size zero-padded buffers. This combined with the fact that QSPECs no longer have a length field and an off-by-one bug in my code caused me some headache. I was very confused about an empty "Control Information" object that seemed to be at the end of the QSPEC. Oh, one more thing: For consistency and flexibility it would be nice if a few Object Types could be reserved for private use like this is done for QOSM IDs and Parameter IDs. Thanks, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 23 04:52:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EerIs-0001nb-5Q; Wed, 23 Nov 2005 04:52:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EerIp-0001kn-Do; Wed, 23 Nov 2005 04:52:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05748; Wed, 23 Nov 2005 04:51:54 -0500 (EST) Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EerRV-0005Du-8r; Wed, 23 Nov 2005 05:01:34 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 23 Nov 2005 10:34:24 +0100 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Nov 2005 10:34:24 +0100 Message-Id: <5F9130612D07074EB0A0CE7E69FD7A0306430A70@S4DE8PSAAGS.blf.telekom.de> From: "Geib, Ruediger" To: rbriscoe@jungle.bt.co.uk Subject: RE: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternate s-02.txt Date: Wed, 23 Nov 2005 10:34:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: karagian@cs.utwente.nl, attila.bader@ericsson.com, tsvwg@ietf.org, nsis@ietf.org, floyd@icir.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Bob, =20 |Why don't the changes to RSVP and NSIS (that I=20 |repeat below) resolve the conflict between=20 |end-to-end and edge-to-edge semantics? The=20 |conflict only occurs for flows within a=20 |signalled reservation, so the conflict can be=20 |resolved in the signalling. If the conflict=20 |is resolved, this proposal should satisfy=20 |Sally's requirements for specifying alternate=20 |semantics for ECN in an edge-edge scenario. I read one of your drafts. If I understood things=20 right, you virtually limit the resources available=20 to packets of a certain DSCP. Once the limit=20 is approached on any link operated according to=20 your scheme, this is indicated by using ECN.=20 Finally, a router interprets and re-writes the=20 ECN field. My personal view is: - The way you apply ECN within the backbone seems=20 to be conforming to the aims of ECN. There in=20 fact is a congestion of the specific resource=20 identified by a packets DSCP. - I personally may prefer the ECN field remaining=20 unchanged, once congestion is indicated. Wouldn't=20 this make your proposed architecture ECN conformant?=20 Further, capable end-systems could renegotiate=20 Codecs. As an additional result, a few more sessions could=20 be accepted.=20 Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 23 06:01:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EesNd-00042S-Tw; Wed, 23 Nov 2005 06:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EesNb-0003yC-Sv; Wed, 23 Nov 2005 06:01:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13746; Wed, 23 Nov 2005 06:00:57 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EesgP-0001e9-Uy; Wed, 23 Nov 2005 06:21:04 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id jANB1MBq000407; Wed, 23 Nov 2005 12:01:22 +0100 (MET) Message-ID: <001901c5f01d$3e4a4620$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Geib, Ruediger" , References: <5F9130612D07074EB0A0CE7E69FD7A0306430A70@S4DE8PSAAGS.blf.telekom.de> Subject: Re: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt Date: Wed, 23 Nov 2005 12:01:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: -5.582 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 23 Nov 2005 12:01:24 +0100 (MET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by denhaag.ewi.utwente.nl id jANB1MBq000407 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: floyd@icir.org, tsvwg@ietf.org, nsis@ietf.org, attila.bader@ericsson.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Ruediger The same protocol semantics (in terms of (pre-)congestion notification and severe congestion [pre-emption]) are supported by using DSCP re-marking within the edge to edge domain. In this way the end-to-end ECN filed is not changed within the edge to edge domain and capable end-systems are able to renegotiate Codecs. Best Regards, Georgios ----- Original Message -----=20 From: "Geib, Ruediger" To: Cc: ; ; ;=20 ; Sent: Wednesday, November 23, 2005 10:34 AM Subject: RE: [NSIS] Re: [Tsvwg] Re: additions on=20 draft-floyd-ecn-alternates-02.txt > Hi Bob, > > |Why don't the changes to RSVP and NSIS (that I > |repeat below) resolve the conflict between > |end-to-end and edge-to-edge semantics? The > |conflict only occurs for flows within a > |signalled reservation, so the conflict can be > |resolved in the signalling. If the conflict > |is resolved, this proposal should satisfy > |Sally's requirements for specifying alternate > |semantics for ECN in an edge-edge scenario. > > I read one of your drafts. If I understood things > right, you virtually limit the resources available > to packets of a certain DSCP. Once the limit > is approached on any link operated according to > your scheme, this is indicated by using ECN. > Finally, a router interprets and re-writes the > ECN field. > > My personal view is: > > - The way you apply ECN within the backbone seems > to be conforming to the aims of ECN. There in > fact is a congestion of the specific resource > identified by a packets DSCP. > > - I personally may prefer the ECN field remaining > unchanged, once congestion is indicated. Wouldn't > this make your proposed architecture ECN conformant? > Further, capable end-systems could renegotiate > Codecs. > > As an additional result, a few more sessions could > be accepted. > > Regards, > > R=FCdiger > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 23 18:51:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef4Ot-0000r2-1o; Wed, 23 Nov 2005 18:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef4Oq-0000ou-PD; Wed, 23 Nov 2005 18:51:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17429; Wed, 23 Nov 2005 18:51:01 -0500 (EST) From: philip.eardley@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef4fF-0004ix-9K; Wed, 23 Nov 2005 19:08:38 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 23:48:47 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Nov 2005 23:48:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 23:48:46 -0000 Message-ID: Thread-Topic: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-marking can do it Thread-Index: AcXsSs5xjS0kMENZTtmcDCBuyp5n3QEPNdB4 To: X-OriginalArrivalTime: 23 Nov 2005 23:48:47.0517 (UTC) FILETIME=[7261FCD0:01C5F088] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-marking can do it X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org some comments below. best wishes, phil ________________________________ * To: >=20 * Subject: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP = re-marking can do it=20 * From: "Georgios Karagiannis" >=20 * Date: Mon, 21 Nov 2005 10:52:22 +0100=20 * Cc: tsvwg at ietf.org , nsis at ietf.org = =20 Hi Bob In addition to the previous discussion I would like to discuss and ask you the following. [chop] What is the technical reason of using ECN for edge-toedge congestion = control, when the same solution (on providing admission control based on congestion notification and severe congestion [pre-emption]) can be provided by using DSCP re-marking? =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 23 18:53:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef4Qz-0002Iw-5M; Wed, 23 Nov 2005 18:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef4PM-0001OB-H1; Wed, 23 Nov 2005 18:52:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17762; Wed, 23 Nov 2005 18:51:30 -0500 (EST) From: philip.eardley@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef4Tf-00047w-Vi; Wed, 23 Nov 2005 18:56:40 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 23:36:55 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Nov 2005 23:36:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt Date: Wed, 23 Nov 2005 23:36:53 -0000 Message-ID: Thread-Topic: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt Thread-Index: AcXwFCPsYYs788JHSvy++7ZiKiB+FwAb91wP To: , X-OriginalArrivalTime: 23 Nov 2005 23:36:54.0901 (UTC) FILETIME=[C9A16A50:01C5F086] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, nsis@ietf.org, floyd@icir.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org rudi thanks very much for your comments. a few follow-ups in line below best wishes phil=20 ________________________________ From: tsvwg-bounces@ietf.org on behalf of Geib, Ruediger Sent: Wed 23/11/2005 09:34 To: Briscoe,RJ,Bob,XVR9 BRISCORJ R Cc: tsvwg@ietf.org; nsis@ietf.org; floyd@icir.org Subject: RE: [NSIS] Re: [Tsvwg] Re: additions on = draft-floyd-ecn-alternates-02.txt=20 Hi Bob, |Why don't the changes to RSVP and NSIS (that I |repeat below) resolve the conflict between |end-to-end and edge-to-edge semantics? The |conflict only occurs for flows within a |signalled reservation, so the conflict can be |resolved in the signalling. If the conflict |is resolved, this proposal should satisfy |Sally's requirements for specifying alternate |semantics for ECN in an edge-edge scenario. I read one of your drafts. If I understood things right, you virtually limit the resources available to packets of a certain DSCP.=20 [phil] yes that's right. note that your "resources available" =3D the = rate defined as the adm ctrl threshold. This could (probably should) be = a lot less than the rate at which pkts start to be dropped, becuase the = link capacity is exceeded.=20 Once the limit is approached on any link operated according to your scheme, this is indicated by using ECN. Finally, a router interprets and re-writes the ECN field. My personal view is: - The way you apply ECN within the backbone seems to be conforming to the aims of ECN. There in fact is a congestion of the specific resource identified by a packets DSCP. [phil] note that ECN marking is used as a notification of pre-congestion = (compare point above) - I personally may prefer the ECN field remaining unchanged, once congestion is indicated.=20 [phil] if you mean remain unchanged when the pkt travels outside the = Diffserv domain (termed CL-domain in the i-d), then i disagree. in the = CL-domain the ECN marking is used for adm ctrl purposes. the usage = foreseen in RFC3168 is for active queue mgt. this leads to different = algorithm for setting the CE codepoint.=20 Wouldn't this make your proposed architecture ECN conformant? [phil] we believe it's already conformant with rfc3168. since the ce = codepoint is used to indicate incipient congestion. the algorithm for = deciding whether to set it isnt RED, but this isnt in conflict with = rfc3168. (The key difference is that RED looks at the length of the real = queue, whereas our algorithm looks at the length of a virtual queue - = the latter is emptied at a slower rate than the real queue, so the ce = codepoint is set before the length of the real queue has started to = increase.) Further, capable end-systems could renegotiate Codecs. [phil] as bob says, if the end-to-end ecn information is really needed = inside an end-to-end reservation, then the info can be delivered through = the signalling across the CL-domain (not that i'm yet convinced that's = needed) - and then your codec renegotiation can still happen. As an additional result, a few more sessions could be accepted. Regards, R=FCdiger _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 23 19:27:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef4xs-0001pD-Kx; Wed, 23 Nov 2005 19:27:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef4xq-0001nC-IN; Wed, 23 Nov 2005 19:27:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21630; Wed, 23 Nov 2005 19:27:11 -0500 (EST) From: philip.eardley@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef5Gm-0006rC-UR; Wed, 23 Nov 2005 19:47:26 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Nov 2005 00:27:30 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Nov 2005 00:27:29 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 00:23:55 -0000 Message-ID: Thread-Topic: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it Thread-Index: AcXsSs5xjS0kMENZTtmcDCBuyp5n3QEPNdB4AAFtPEw= To: , X-OriginalArrivalTime: 24 Nov 2005 00:27:29.0613 (UTC) FILETIME=[DA75B7D0:01C5F08D] X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hit send too early last time, =20 =20 >>What is the technical reason of using ECN for edge-toedge congestion = control? The use of Ecn seems natural to me, since we wnat the network to = indicate incipient congestion and that's what ECN is supposed to do. = Note that the semantics are the same as rfc3168 (ECN) - ie same = codepoints of ECN field and CE codepoint indicates incipient congestion. = I also think it can help with migration to a fully ecn world. As = operators get experience of using ecn, whilst not requiring all nws / = end hosts to be using it.=20 Second, using DSCP re-marking seems to need a lot of DSCPs. According to = your draft, admission control implies 2 per traffic class (one for = re-marked pkts, one for other pkts passing thru the same router). Plus = another for the severe congestion indication. In addition, in the core = network an interesting future extension is to use the mechanisms in a = network with MPLS-TE (see our framework draft for brief discussion) - = there isnt sufficient space in the label for these extra dscps.=20 Third, (as bob has pointed out) that it's easy to overcome the = end-to-end vs edge-to-edge marking issue (if that's really needed, which = I'm inclined to think it isnt) ________________________________ From: tsvwg-bounces@ietf.org on behalf of philip.eardley@bt.com Sent: Wed 23/11/2005 23:48 To: karagian@cs.utwente.nl Cc: tsvwg@ietf.org; nsis@ietf.org Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP = re-markingcan do it some comments below. best wishes, phil ________________________________ * To: = > * Subject: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP = re-marking can do it * From: "Georgios Karagiannis" > * Date: Mon, 21 Nov 2005 10:52:22 +0100 * Cc: tsvwg at ietf.org , nsis at = ietf.org =20 Hi Bob In addition to the previous discussion I would like to discuss and ask you the following. [chop] What is the technical reason of using ECN for edge-toedge congestion = control, when the same solution (on providing admission control based on congestion notification and severe congestion [pre-emption]) can be provided by using DSCP re-marking? _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 24 03:19:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCJo-0004TB-KM; Thu, 24 Nov 2005 03:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCJl-0004T0-6c; Thu, 24 Nov 2005 03:18:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29931; Thu, 24 Nov 2005 03:18:17 -0500 (EST) Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfCcl-0001se-K7; Thu, 24 Nov 2005 03:38:37 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 24 Nov 2005 09:18:38 +0100 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Nov 2005 09:18:38 +0100 Message-Id: <5F9130612D07074EB0A0CE7E69FD7A0306430A7D@S4DE8PSAAGS.blf.telekom.de> From: "Geib, Ruediger" To: philip.eardley@bt.com, rbriscoe@jungle.bt.co.uk Subject: RE: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternate s-02.txt Date: Thu, 24 Nov 2005 09:18:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, nsis@ietf.org, floyd@icir.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Phil, some more thoughts in line. Regards, R=FCdiger [snip] |My personal view is: | |- The way you apply ECN within the backbone seems | to be conforming to the aims of ECN. There in | fact is a congestion of the specific resource | identified by a packets DSCP. | |[phil] note that ECN marking is used as a notification |of pre-congestion (compare point above) [Rudi] that might be a philosophical question. The ECN=20 marking informs a router that no more sessions should=20 be admitted / the traffic on a link needs to be=20 throttled. Isn't that the purpose of ECN too? CL resources may be dimensioned to carry traffic of=20 another link without causing CL losses and leave space=20 for other services. In my eyes, that's a clear benefit,=20 as it allows for network based flow control of elastic=20 and inelastic traffic in the same network. Admission=20 control is an important part of inelastic flow control. | |- I personally may prefer the ECN field remaining | unchanged, once congestion is indicated.=20 | |[phil] if you mean remain unchanged when the pkt travels=20 |outside the Diffserv domain (termed CL-domain in the i-d),=20 |then i disagree. in the CL-domain the ECN marking is used for=20 |adm ctrl purposes. the usage foreseen in RFC3168 is for active=20 |queue mgt. this leads to different algorithm for setting the=20 |CE codepoint.=20 [Rudi] Good point. I made an assumption which I didn't mention.=20 I assume a signaling/reservation based admission control=20 outside the DiffServ region. This should avoid congestion and=20 the set ECN bits shouldn't cause any harm there. |Wouldn't | this make your proposed architecture ECN conformant? | |[phil] we believe it's already conformant with rfc3168. since=20 |the ce codepoint is used to indicate incipient congestion. the=20 |algorithm for deciding whether to set it isnt RED, but this=20 |isnt in conflict with rfc3168. (The key difference is that RED=20 |looks at the length of the real queue, whereas our algorithm=20 |looks at the length of a virtual queue - the latter is emptied=20 |at a slower rate than the real queue, so the ce codepoint is=20 |set before the length of the real queue has started to increase.) [Rudi] I agree. All I asked is whether re-writing the ECN bits=20 is ECN conformant. | Further, capable end-systems could renegotiate | Codecs. | | |[phil] as bob says, if the end-to-end ecn information is=20 |really needed inside an end-to-end reservation, then the info=20 |can be delivered through the signalling across the CL-domain=20 |(not that i'm yet convinced that's needed) - and then your=20 |codec renegotiation can still happen. [Rudi] Yes, sure. I don't build routers and if the people doing=20 it say "the router inspects all the packets anyway, adding the=20 ECN evaluation and triggering a new signaling message doesn't=20 add significant processing load", I'm convinced of Bob's point.=20 Otherwise, the end system should be involved.=20 Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 24 04:28:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfDOz-0005hr-DQ; Thu, 24 Nov 2005 04:28:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfDOy-0005hO-BI; Thu, 24 Nov 2005 04:28:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06651; Thu, 24 Nov 2005 04:27:43 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfDhz-0004bl-57; Thu, 24 Nov 2005 04:48:04 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id jAO9SDMx007952; Thu, 24 Nov 2005 10:28:17 +0100 (MET) Message-ID: <004a01c5f0d9$67d41950$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: References: Date: Thu, 24 Nov 2005 10:28:09 +0100 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: -5.585 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 24 Nov 2005 10:28:19 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Phil Please see in line! ----- Original Message ----- From: To: ; Cc: ; Sent: Thursday, November 24, 2005 1:23 AM Subject: RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it > hit send too early last time, > >>>What is the technical reason of using ECN for edge-toedge congestion >>>control? > The use of Ecn seems natural to me, since we wnat the network to indicate > incipient congestion and that's what ECN is supposed to do. Note that the > semantics are the same as rfc3168 (ECN) - ie same codepoints of ECN field > and CE codepoint indicates incipient congestion. I also think it can help > with migration to a fully ecn world. As operators get experience of using > ecn, whilst not requiring all nws / end hosts to be using it. Georgios: yes I understand but the ECN semantics apply end-to-end, not edge-toedge, please see the previous discussions on this issue! > > Second, using DSCP re-marking seems to need a lot of DSCPs. According to > your draft, admission control implies 2 per traffic class (one for > re-marked pkts, one for other pkts passing thru the same router). Plus > another for the severe congestion indication. In addition, in the core > network an interesting future extension is to use the mechanisms in a > network with MPLS-TE (see our framework draft for brief discussion) - > there isnt sufficient space in the label for these extra dscps. Georgios: regarding the number of DSCP's you are right, but there are ways of reducing this number, please see the RMD draft. Please also note that the streaming aplication example that has been discussed in the tsvwg and nsis mailing lists shows that it is usefull to use end-to-end ECN based congestion control for reserved traffic. This streaming application example can very efficiently use RSVP and the DCCP protocol (which uses the end-to-end ECN concept). Please also note that the support of this type of this type of streaming application that combines the end to end ECN semantics with reserved minimum bandwidth is needed not only in the backbone network but also in the wireless network as well. Therefore the rate-adaptation function of ECN (DCCP functionality) combined with minimum bandwidth reservation can be very important. > Third, (as bob has pointed out) that it's easy to overcome the end-to-end > vs edge-to-edge marking issue (if that's really needed, which I'm inclined to think it isnt) Georgios: regarding this point I am not sure if it is easy! It depends on the imposed additional complexity. Best regards, Georgios > > ________________________________ > > From: tsvwg-bounces@ietf.org on behalf of philip.eardley@bt.com > Sent: Wed 23/11/2005 23:48 > To: karagian@cs.utwente.nl > Cc: tsvwg@ietf.org; nsis@ietf.org > Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP > re-markingcan do it > > > > some comments below. > > best wishes, phil > > ________________________________ > > * To: > > * Subject: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP > re-marking can do it > * From: "Georgios Karagiannis" > > * Date: Mon, 21 Nov 2005 10:52:22 +0100 > * Cc: tsvwg at ietf.org , nsis at > ietf.org > > Hi Bob > > In addition to the previous discussion I would like to > discuss and ask you the following. > > [chop] > What is the technical reason of using ECN for edge-toedge congestion > control, > when the same solution (on providing admission control > based on congestion notification and severe > congestion [pre-emption]) can be provided by using DSCP re-marking? > > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 24 16:29:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfOfH-000829-6l; Thu, 24 Nov 2005 16:29:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfOfF-00081y-IL; Thu, 24 Nov 2005 16:29:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27551; Thu, 24 Nov 2005 16:29:16 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfOyN-0008Po-Dd; Thu, 24 Nov 2005 16:49:43 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAOLQZD02415; Thu, 24 Nov 2005 16:26:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt Date: Thu, 24 Nov 2005 16:26:25 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650729B359@zcarhxm1.corp.nortel.com> Thread-Topic: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt Thread-Index: AcXw0A5ivhKHyiN6SkizqgGNFnDMqwAa2SuQ From: "Jozef Babiarz" To: "Geib, Ruediger" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, nsis@ietf.org, floyd@icir.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org [snip] | Further, capable end-systems could renegotiate | Codecs. | | |[phil] as bob says, if the end-to-end ecn information is |really needed inside an end-to-end reservation, then the info=20 |can be delivered through the signalling across the CL-domain=20 |(not that i'm yet convinced that's needed) - and then your=20 |codec renegotiation can still happen. [Rudi] Yes, sure. I don't build routers and if the people doing=20 it say "the router inspects all the packets anyway, adding the=20 ECN evaluation and triggering a new signaling message doesn't=20 add significant processing load", I'm convinced of Bob's point.=20 Otherwise, the end system should be involved. [joe] I believe that there is lot of value of having ECN marking = end-to-end. If the application is informed of pre-congestion, it can = take action with out the complexity of the edge router know the detailed = capability about the flow, like that it can or can not change its codec = and reduce its sending rate. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of Geib, Ruediger Sent: Thursday, November 24, 2005 3:19 AM To: philip.eardley@bt.com; rbriscoe@jungle.bt.co.uk Cc: tsvwg@ietf.org; nsis@ietf.org; floyd@icir.org Subject: RE: [NSIS] Re: [Tsvwg] Re: additions on = draft-floyd-ecn-alternates-02.txt=20 Hi Phil, some more thoughts in line. Regards, R=FCdiger [snip] |My personal view is: | |- The way you apply ECN within the backbone seems | to be conforming to the aims of ECN. There in | fact is a congestion of the specific resource | identified by a packets DSCP. | |[phil] note that ECN marking is used as a notification |of pre-congestion (compare point above) [Rudi] that might be a philosophical question. The ECN=20 marking informs a router that no more sessions should=20 be admitted / the traffic on a link needs to be=20 throttled. Isn't that the purpose of ECN too? CL resources may be dimensioned to carry traffic of=20 another link without causing CL losses and leave space=20 for other services. In my eyes, that's a clear benefit,=20 as it allows for network based flow control of elastic=20 and inelastic traffic in the same network. Admission=20 control is an important part of inelastic flow control. | |- I personally may prefer the ECN field remaining | unchanged, once congestion is indicated.=20 | |[phil] if you mean remain unchanged when the pkt travels=20 |outside the Diffserv domain (termed CL-domain in the i-d),=20 |then i disagree. in the CL-domain the ECN marking is used for=20 |adm ctrl purposes. the usage foreseen in RFC3168 is for active=20 |queue mgt. this leads to different algorithm for setting the=20 |CE codepoint.=20 [Rudi] Good point. I made an assumption which I didn't mention.=20 I assume a signaling/reservation based admission control=20 outside the DiffServ region. This should avoid congestion and=20 the set ECN bits shouldn't cause any harm there. |Wouldn't | this make your proposed architecture ECN conformant? | |[phil] we believe it's already conformant with rfc3168. since=20 |the ce codepoint is used to indicate incipient congestion. the=20 |algorithm for deciding whether to set it isnt RED, but this=20 |isnt in conflict with rfc3168. (The key difference is that RED=20 |looks at the length of the real queue, whereas our algorithm=20 |looks at the length of a virtual queue - the latter is emptied=20 |at a slower rate than the real queue, so the ce codepoint is=20 |set before the length of the real queue has started to increase.) [Rudi] I agree. All I asked is whether re-writing the ECN bits=20 is ECN conformant. | Further, capable end-systems could renegotiate | Codecs. | | |[phil] as bob says, if the end-to-end ecn information is=20 |really needed inside an end-to-end reservation, then the info=20 |can be delivered through the signalling across the CL-domain=20 |(not that i'm yet convinced that's needed) - and then your=20 |codec renegotiation can still happen. [Rudi] Yes, sure. I don't build routers and if the people doing=20 it say "the router inspects all the packets anyway, adding the=20 ECN evaluation and triggering a new signaling message doesn't=20 add significant processing load", I'm convinced of Bob's point.=20 Otherwise, the end system should be involved.=20 Regards, R=FCdiger _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 24 18:55:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQwH-0004Xz-4t; Thu, 24 Nov 2005 18:55:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQwF-0004W2-4a; Thu, 24 Nov 2005 18:55:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13883; Thu, 24 Nov 2005 18:54:57 -0500 (EST) From: philip.eardley@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfRFO-0005L8-JS; Thu, 24 Nov 2005 19:15:27 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Nov 2005 23:55:28 +0000 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Nov 2005 23:55:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 23:55:26 -0000 Message-ID: Thread-Topic: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it Thread-Index: AcXw2WrrgYEsnI1SRoiUQhWfXImjUwAd1ISA To: X-OriginalArrivalTime: 24 Nov 2005 23:55:28.0070 (UTC) FILETIME=[8B8B4660:01C5F152] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, nsis@ietf.org Subject: [NSIS] RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org more follow-up in-line best wishes phil -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: Thu 24/11/2005 09:28 To: Eardley,PL,Philip,CXR9 R Cc: tsvwg@ietf.org; nsis@ietf.org Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP = re-markingcan do it =20 Hi Phil Please see in line! ----- Original Message -----=20 From: To: ; Cc: ; Sent: Thursday, November 24, 2005 1:23 AM Subject: RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP=20 re-markingcan do it > hit send too early last time, > >>>What is the technical reason of using ECN for edge-toedge congestion=20 >>>control? > The use of Ecn seems natural to me, since we wnat the network to = indicate=20 > incipient congestion and that's what ECN is supposed to do. Note that = the=20 > semantics are the same as rfc3168 (ECN) - ie same codepoints of ECN = field=20 > and CE codepoint indicates incipient congestion. I also think it can = help=20 > with migration to a fully ecn world. As operators get experience of = using=20 > ecn, whilst not requiring all nws / end hosts to be using it. Georgios: yes I understand but the ECN semantics apply end-to-end, not=20 edge-toedge, please see the previous discussions on this issue! [phil] your original question was "why use edge-to-edge ECN re-marking = when DSCP re-marking can do it". i think from your reply ["yes i = understand"] you're saying that you agree edge-to-edge ECN re-marking is = better than DSCP re-marking, providing your end-to-end concern is = addressed.=20 > > Second, using DSCP re-marking seems to need a lot of DSCPs. According = to=20 > your draft, admission control implies 2 per traffic class (one for=20 > re-marked pkts, one for other pkts passing thru the same router). Plus = > another for the severe congestion indication. In addition, in the core = > network an interesting future extension is to use the mechanisms in a=20 > network with MPLS-TE (see our framework draft for brief discussion) -=20 > there isnt sufficient space in the label for these extra dscps. Georgios: regarding the number of DSCP's you are right, but there are = ways of reducing this number, please see the RMD draft. [phil] actually i already took account of the reduction explained in the = draft. which is that all 3 drop precedences of AF are re-marked to the = same dscp. do you have any other suggestions how to reduce the number of = dscps required? Please also note that the streaming aplication example that has been=20 discussed in the tsvwg and nsis mailing lists shows that it is usefull to use end-to-end ECN based congestion control for reserved traffic. [phil] i dont think anyone answered louise's question - that excess = traffic above the reservation level will be dropped or treated as best = effort by an operator? This streaming application example can very efficiently use RSVP and the DCCP protocol (which uses the end-to-end ECN concept). [phil] why do you mention dccp in particular? after all rfc3168 includes = stuff about how to add ecn reactivity to tcp. Please also note that the support of this type of this type of streaming = application that combines the end to end ECN semantics with reserved minimum bandwidth is needed not only in the backbone network but also in the wireless network as well. Therefore the rate-adaptation function of ECN (DCCP functionality) combined with minimum bandwidth reservation can be very important. > Third, (as bob has pointed out) that it's easy to overcome the = end-to-end=20 > vs edge-to-edge marking issue (if that's really needed, which I'm inclined to think it = isnt) Georgios: regarding this point I am not sure if it is easy! It depends = on=20 the imposed additional complexity. [phil] note that the additional complexity is at teh edge of the core = network, where it should be ok (at least it's the point where complex = things are done). also, i think the migration point that i made in my previous email is = very important. at present, even if both end terminals are ecn capable, = the chances are that at least one of the networks in between isnt. how = do we move to a situation where all the networks have deployed ecn? the = edge-to-edge case provides a good reason for an operator to deploy ecn = capability. so it makes it more likely that your end-to-end ecn case can = happen - as people gain experience in ecn. Best regards, Georgios > > ________________________________ > > From: tsvwg-bounces@ietf.org on behalf of philip.eardley@bt.com > Sent: Wed 23/11/2005 23:48 > To: karagian@cs.utwente.nl > Cc: tsvwg@ietf.org; nsis@ietf.org > Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP=20 > re-markingcan do it > > > > some comments below. > > best wishes, phil > > ________________________________ > > * To: > > * Subject: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP = > re-marking can do it > * From: "Georgios Karagiannis" > > * Date: Mon, 21 Nov 2005 10:52:22 +0100 > * Cc: tsvwg at ietf.org , nsis at=20 > ietf.org > > Hi Bob > > In addition to the previous discussion I would like to > discuss and ask you the following. > > [chop] > What is the technical reason of using ECN for edge-toedge congestion=20 > control, > when the same solution (on providing admission control > based on congestion notification and severe > congestion [pre-emption]) can be provided by using DSCP re-marking? > > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 24 19:29:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfRSo-0000ql-S8; Thu, 24 Nov 2005 19:29:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfRSn-0000qT-1I for nsis@megatron.ietf.org; Thu, 24 Nov 2005 19:29:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17629 for ; Thu, 24 Nov 2005 19:28:35 -0500 (EST) Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfRls-0006Wf-8N for nsis@ietf.org; Thu, 24 Nov 2005 19:49:05 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 00:28:58 +0000 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 00:28:58 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 00:28:57 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1132878536481; Fri, 25 Nov 2005 00:28:56 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.1]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id jAP0SrDr023009; Fri, 25 Nov 2005 00:28:54 GMT Message-Id: <5.2.1.1.2.20051124132637.04026108@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 24 Nov 2005 17:40:38 +0000 To: "Georgios Karagiannis" From: Bob Briscoe Subject: Re: [NSIS] Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it In-Reply-To: <004a01c5f0d9$67d41950$4c0d5982@dynamic.ewi.utwente.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Nov 2005 00:28:57.0816 (UTC) FILETIME=[39722D80:01C5F157] X-Spam-Score: 0.6 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: philip.eardley@bt.com, tsvwg@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios, (long e-mail) We thought long and hard about which re-marking to use. My primary concern was to keep the Internet architecture consistent, which leads to the arguments below. 1/ Intended semantics of the Internet Architecture ================================================== 1.1/ Intended re-marking semantics of Diffserv & ECN -------------------------------------------------- Diffserv re-marking was defined for two reasons: i) To allow the ingress of a Diffserv domain to prevent traffic in excess of the contracted rate/burstiness from being given favourable treatment at downstream routers if they became congested themselves. ii) To allow a border router to map the DSCP used for a per-hop behaviour in the upstream domain to that used for the same PHB in the downstream domain. ECN re-marking is used by a node to indicate that the node itself is approaching congestion. The intent is to reduce the load from the source, but marking is forwarded downstream in the expectation that it will be fed back to the source. Thus, the intent of Diffserv re-marking is to alter the downstream per hop forwarding behaviour if necessary. Diffserv re-marking was not intended to be fed back to the source. The intent of ECN re-marking is to reduce the load at source through feedback. ECN re-marking was specifically not intended to alter the downstream forwarding behaviour of re-marked packets. That's the idealistic view. In practice, it can be convenient to break architecture. But architecture is there to warn you to think long and hard when you depart from it, so you are aware of what you might break in the future. 1.2/ Was ECN at the IP layer intended to have end-to-end semantics? ------------------------------------------------------------------- RFC3168 was written so that the ECN semantics in IP could be separated from the end-to-end ECN semantics of TCP when other ECN transports were defined. [According to Sally Floyd at the time, the main reason for specifying ECN for TCP & IP together in the same RFC was to encourage the first experiments with ECN to be in TCP implementations which tend to be written with a lot more care by a few kernel experts.] Indeed, Jon Crowcroft and I wrote an I-D reviewing the ECN I-D before it became RFC3168. In section 12, we proposed text on ECN semantics for proxies (edge-to-edge), asking that it be added to the ECN RFC: (Expired) Sally Floyd's response (off-line) at the time is quoted here: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ At 11:35 21/02/01 -0800, Sally Floyd wrote: >Feedback on Section 12, proposing rules for allowing proxies in the >network to change ECN codepoints: > >I think that this is complicated, and has to be dealt with in a >separate document, in context. That is, when people have specific >proposals for intermediate nodes to modify the ECN field, >then I think they have to be addressed at that time. My own opinion >is that making general rules ahead of time, in the abstract, >such as "we will now propose rules for changing the ECN >capability of a packet at intermediate nodes", never gets it right. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ is exactly that. A separate document about the semantics of ECN proxies, in this case with a flow signalling transport like RSVP (or NSIS). The idea of RMD and of is for the node at the end of a long signalling 'hop' (a whole Diffserv region) to see how much congestion has accumulated since the start of the region. Potentially there may be other signalling 'hops' further downstream using the same technique again. So the egress of one signalling hop must tidy things up by folding any re-marked packets back in to the same marking as un-re-marked packets, to avoid confusing further region(s) downstream if they are using the same technique. [For instance, you are thinking of RMD being used for admission control across a radio access network. But there may be another RAN at the other end of the network using the same technique. So you must ensure any re-marked DSCPs are folded back into the same DSCP as non-re-marked packets at the RMD egress. ] 1.3/ Summary of architectural concerns -------------------------------------- To indicate the need for admission control, it is certainly more convenient to do Diffserv re-marking as RMD does, but I believe it is more architecturally consistent to use ECN re-marking, as we do. However, architecture is like religion. You can break it, if it becomes too inconvenient, and if you can convince enough people you have a good excuse. 2. Practical issues ------------------- I don't think we need to break the architecture in this case (which is why we use ECN), but using ECN re-marking edge-edge does raise the following issue... 2.1/ Edge-to-edge ECN conflicts with end-to-end ECN --------------------------------------------------- We fully understand that use of ECN re-marking to trigger admission control within Diffserv regions would conflict with end-to-end ECN congestion control for the *same* flow. But we deliberately chose to specify the end to end service we were providing as "controlled load [RFC2211]" to try to preclude such cases. RFC 2211 says: " ... 2. End-to-End Behavior ... Should the client's traffic generation properties fall outside of the region described by the TSpec parameters, the QoS provided to the client may exhibit characteristics indicative of overload, including large numbers of delayed or dropped packets. ... 7. Policing ... the network element MUST attempt to forward the excess traffic on a best-effort basis if sufficient resources are available ... Beyond requirements 2 and 3 above, the controlled-load service does not define the QoS behavior delivered to flows with non-conformant arriving traffic. Specifically, it is permissible either to degrade the service delivered to all of the flow's packets equally, or to sort the flow's packets into a conformant set and a nonconformant set and deliver different levels of service to the two sets. ... 9. Guidelines for Implementors ... If most controlled-load traffic arises from rate-adaptive realtime or elastic applications attempting to establish a bounded minimum level of service, the use of separate resource classes might be preferable. " I won't paste everything RF2211 says on with advice for implementors on scheduling elastic flows with a bounded minimum, as there's rather a lot. But basically, you get unavoidably bad re-ordering and other complications that make it hard. Even though this seems a desirable service, it's unlikely to work well in practice. 2.2/ End-to-end ECN conflicts with edge-to-edge admission control ----------------------------------------------------------------- The congestion-based admission control mechanism used in RMD and in our would break if a significant proportion of admitted traffic were adaptive. If congestion on an interior path were close to the threshold where admission control was needed, adaptive traffic might temporarily drop well below its minimum bound. More flows might then be accepted, then the adaptive traffic could grow again, destroying the controlled load service for all flows through that path. [Note: Variable bit rate (VBR) like video traffic would superfically seem to break a measurement-based admission control system in the same way as adaptive traffic. But unlike with adaptive traffic, troughs in VBR load are not correlated with congestion. Our analyses of how the effective bandwidth of VBR (and silence-suppressed voice) aggregates has shown that our solution works OK for VBR, given specific conditions on the amount of aggregation and provided VBR traffic sources are not correlated. We are currently preparing this analysis for publication.] 2.3/ Summary of end/edge conflicts ---------------------------------- So, we prefer to say that a different service would have to be requested to cater for your hybrid requirement. Hence my preference for explicitly requesting "adaptive rate control with a bounded minimum" in the signalling, as a different QoS service. In NSIS terms, this is would be in the QSPEC, I believe. 2.4/ Codepoint space -------------------- Real-estate in the IP header is at a premium. Treating the 6-bit Diffserv field and the 2-bit ECN field separately leads to 2^6 + 2^2 = 68 codepoints. Treating them together leads to 2^8 = 256 codepoints. In the MPLS EXP field, real-estate is a far greater headache. If ECN marking is orthogonal to Diffserv marking for most Diffserv codepoints, it makes sense to treate the field as 6-bit and 2-bit sub-fields. But I don't believe we should be averse to bending the rules to save codepoint space across both fields. For instance both our approach and RMD need another marking state for a router in the Diffserv interior to indicate the need for flow pre-emption (eg. after re-routes). Pre-emption represents severe congestion and needs to be fed back upstream. So by my arguments above pre-emption should be re-marked using the ECN field. But in our current pre-emption solution, if two or more nodes in a path require some flows to be pre-empted, packets that have already been re-marked once to indicate pre-emption need to be treated differently by downstream nodes. So by my arguments above pre-emption should also be re-marked using the DSCP. Well, it would be silly to waste two codepoints for one state. And there aren't enough ECN codepoints anyway. So, IMHO, you have to be pragmatic and be willing to re-mark the Diffserv codepoint for pre-emption (CAVEAT: the authors of still haven't reached consensus on marking - that's why hasn't been updated yet). 7/ Consistent meaning of an ECN marking --------------------------------------- I hope I have answered your question about why we use ECN not Diffserv re-marking. We are not completely inflexible about using ECN, but I do have further reasons for preferring ECN re-marking---to do with the economic interpretation of congestion marking across different classes. It would take too long to go into that here, but you can read a recent paper I published on the subject if interested. Commercial Models for IP Quality of Service Interconnect, Bob Briscoe & Steve Rudkin (BT), in BTTJ Special Edition on IP Quality of Service, 23(2) (Apr 2005) I have also given responses inline... At 09:28 24/11/2005, Georgios Karagiannis wrote: >----- Original Message ----- From: >To: ; >Cc: ; >Sent: Thursday, November 24, 2005 1:23 AM >Subject: RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP >re-markingcan do it > > >>>>[GK] What is the technical reason of using ECN for edge-toedge >>>>congestion control? >>[PE] The use of Ecn seems natural to me, since we wnat the network to >>indicate incipient congestion and that's what ECN is supposed to do. Note >>that the semantics are the same as rfc3168 (ECN) - ie same codepoints of >>ECN field and CE codepoint indicates incipient congestion. I also think >>it can help with migration to a fully ecn world. As operators get >>experience of using ecn, whilst not requiring all nws / end hosts to be >>using it. > >Georgios: yes I understand but the ECN semantics apply end-to-end, not >edge-toedge, >please see the previous discussions on this issue! [BB] ECN semantics were originally defined for an end-to-end protocol (TCP). That does not imply they were only intended to ever be end-to-end. RFC3168 did not preclude edge-to-edge. And at least one of the authors believed edge-to-edge semantics could be a valid thing to define later (see quote from Sally Floyd above). >>[PE] Second, using DSCP re-marking seems to need a lot of DSCPs. >>According to your draft, admission control implies 2 per traffic class >>(one for re-marked pkts, one for other pkts passing thru the same >>router). Plus another for the severe congestion indication. In addition, >>in the core network an interesting future extension is to use the >>mechanisms in a network with MPLS-TE (see our framework draft for brief >>discussion) - there isnt sufficient space in the label for these extra dscps. > >Georgios: regarding the number of DSCP's you are right, but there are ways >of reducing this number, please see the RMD draft. >Please also note that the streaming aplication example that has been >discussed in >the tsvwg and nsis mailing lists shows that it is usefull to use >end-to-end ECN based congestion control for reserved traffic. >This streaming application example can very efficiently use RSVP and the >DCCP protocol (which uses the end-to-end ECN concept). [BB] No-one on the list has said it would be efficient. In fact the opposite has been said (by Louise Burness) and no-one has disagreed. I believe this hybrid service should be set aside for someone else to define a mechanism for later. Intserv couldn't even do it very well, even though it had a per-flow scheduler. >[GK] Please also note that the support of this type of this type of >streaming application that >combines the end to end ECN semantics >with reserved minimum bandwidth is needed not only >in the backbone network but also in the wireless network as well. >Therefore the rate-adaptation function of ECN (DCCP functionality) >combined with minimum bandwidth reservation can be very important. [BB] Yes, an adaptive application with a minimum rate would be a desirable service. But it's not the one we are defining. And you will find it doesn't work with RMD's congestion-based admission scheme either. [BB] We are trying to do Controlled Load to scale to the Internet. We don't know how to implement this hybrid at Internet scale. We have had to limit our scope to avoid this hybrid problem. And you will find that such a hybrid service wouldn't work with the mechanism you have defined for RMD either. [BB] So I need to turn your question back on you: how would you prevent adaptive applications using your RMD congestion mechanism, and breaking the admission control system? [BB] The solution I have proposed is to require the application to signal this hybrid requirement and if it is not signalled, to drop any excess traffic at the region ingress in order to disincentivise any adaptive application trying to use the wrong service for its needs. >>Third, (as bob has pointed out) that it's easy to overcome the end-to-end >>vs edge-to-edge >marking issue (if that's really needed, which I'm inclined to think it isnt) > >Georgios: regarding this point I am not sure if it is easy! It depends on the >imposed additional complexity. [BB] If a request for this hybrid were signalled (and an operator chose to support the hybrid service), with the current state of knowledge, I would say that this hybrid traffic would have to be dealt with by a less scalable means, such as Intserv per-flow schedulers on every node, or your hop by hop reservation method in RMD. Bob >Best regards, >Georgios > > >> >>________________________________ >> >>From: tsvwg-bounces@ietf.org on behalf of philip.eardley@bt.com >>Sent: Wed 23/11/2005 23:48 >>To: karagian@cs.utwente.nl >>Cc: tsvwg@ietf.org; nsis@ietf.org >>Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP >>re-markingcan do it >> >> >> >>some comments below. >> >>best wishes, phil >> >>________________________________ >> >>* To: > >>* Subject: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP >>re-marking can do it >>* From: "Georgios Karagiannis" > > >>* Date: Mon, 21 Nov 2005 10:52:22 +0100 >>* Cc: tsvwg at ietf.org , nsis at >>ietf.org >> >>Hi Bob >> >>In addition to the previous discussion I would like to >>discuss and ask you the following. >> >>[chop] >>What is the technical reason of using ECN for edge-toedge congestion control, >>when the same solution (on providing admission control >>based on congestion notification and severe >>congestion [pre-emption]) can be provided by using DSCP re-marking? >> >> >> >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg >> > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 24 19:29:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfRSs-0000sL-02; Thu, 24 Nov 2005 19:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfRSp-0000rZ-Ov for nsis@megatron.ietf.org; Thu, 24 Nov 2005 19:29:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17638 for ; Thu, 24 Nov 2005 19:28:37 -0500 (EST) Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfRly-0006Wi-D7 for nsis@ietf.org; Thu, 24 Nov 2005 19:49:08 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 00:29:06 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Nov 2005 00:29:06 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 00:29:05 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1132878544491; Fri, 25 Nov 2005 00:29:04 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.1]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id jAP0T0Dr023012; Fri, 25 Nov 2005 00:29:03 GMT Message-Id: <5.2.1.1.2.20051124222719.0415cea8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 25 Nov 2005 00:27:46 +0000 To: "Georgios Karagiannis" From: Bob Briscoe In-Reply-To: References: <5.2.1.1.2.20051118190810.040c5f78@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Nov 2005 00:29:05.0769 (UTC) FILETIME=[3E2FB590:01C5F157] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: "tsvwg@ietf.org" , floyd@icir.org, "nsis@ietf.org" , attila.bader@ericsson.com Subject: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Georgios, Replies inline At 12:39 19/11/2005, Georgios Karagiannis wrote: >Hi Bob > >[GK] The streaming aplication example that has been discussed in >the tsvwg and nsis mailing lists shows that it is usefull to use >end-to-end ECN based congestion control for reserved traffic. >This streaming application example can very efficiently use RSVP and the >DCCP protocol (which uses the end-to-end ECN concept). [BB] See the other mail I've just sent on the Subject: "why use edge-to-edge ECN re-marking when DSCP re-markingcan do it". In summary, yes, this hybrid rate adaptive congestion control with a reserved minimum bound rate would probably be useful, but it is not the service we are defining. Our aim is to provide a Controlled Load service that scales well for the global Internet. We don't have a way to scale admission control to the Internet for traffic that is a hybrid of adaptive and reserved in the same flow. I believe you will find that none of the RMD mechanisms based on MBAC will be able to make this hybrid service scale well either (see below for why). The only known way to provide this hybrid service is with an Intserv per-flow scheduler, which doesn't scale well. Even then the service has to be provided with no warranty, because bad packet re-ordering may well result (see my quotes from RFC2211 in the other mail). So I suggest applications need to specifically signal if they want this hybrid service. And if operators wish to provide it, they will have to classify traffic into a hop by hop Intserv path. This won't scale to the Internet, but that is the limit of current knowledge. A hybrid of adaptive and reserved traffic within the same flows breaks measurement-based admission control for the following reason. If congestion on an interior path in our scheme or in the congestion-based RMD scheme were close to the threshold where admission control was needed, adaptive traffic might temporarily drop well below its minimum bound. More flows might then be accepted, then the adaptive traffic could grow again, destroying the controlled load service for all flows through that path. [BB] [Nonetheless, we have shown our measurement-based admission control scheme can handle variable bit rate (VBR) like video (and silence-suppressed voice). We can specify the safety margin needed on the virtual queue for a given amount of traffic aggregation, as long as VBR sources aren't correlated with each other. But MBAC will never be able to manage adaptive traffic, because its load is negatively correlated with congestion, which breaks any MBAC mechanism---not just ours but yours in RMD as well.] >[GK] One can think of situations (applications) where it is not needed to use >end-to-end cc for reserved traffic. Thus I would say that a third option >should be available in the selection process: >c) the ability of using end-to-end ECN based congestion control for >reserved traffic should be possible. Meaning that for some applications >you may use end-to-end ECN based congestion control for reserved traffic >and for other applications you may not use end-to-end ECN based >congestion control for reserved traffic. > >[GK] Regarding your following proposal: > >[BB] To reduce complexity, I would want the > >default for the API to any new signalling stacks to be REQUIRED to be NO > >end-to-end congestion control required. > >[GK] Are you actually indirectly saying that whenever the IETF standardizes a >new signaling protocol this protocol MUST not be used in combination >with the DCCP protocol (which actually uses the end-to-end ECN concept)? [BB] You have taken the quote out of context. In the thread below, it was in the context of new implementations of RSVP or NSIS signalling stacks---if the option I proposed became standardised in RSVP or NSIS to signal the choice between adaptive or non-adaptive Intserv controlled load service (or the equivalent for RMD). In this context, yes, I mean that TCP congestion control or DCCP congestion control would NOT be appropriate for a flow that had signalled that it would not use congestion control. I am saying that it would be a mistake to define an admission controlled reservation service for controlled load to cover both cases (adaptive and non-adaptive) in the same service. I now believe it was a mistake for Intserv to try to do this. We have realised that lumping both services together under one service definition means you can't use any form of MBAC for non-adaptive traffic, just in case you have adaptive traffic. That limits the available mechanisms far too much. I appreciate that QoS service definitions should be independent of the mechanism used to achieve them. But in this case, two related services were lumped together because it was thought they could be achieved with the same mechanism. Caveat: No-one has tried to implement this hybrid service with MBAC, so I'm talking theory not practice here. But when the authors of got together in Vancouver we came up with the same hybrid scenario that you have, and none of us could see how MBAC could work with it, so we believe it should be excluded explicitly. I would still be interested in your views on the proposed protocol defaults as well as the API defaults in the proposal below, now that I have clarified the context. Also, if I am right, what do you intend to do about precluding adaptive flows from your MBAC schemes in RMD? It seems this will require changes to standards track protocols, along with the other changes to standards that RMD will require, if we are to ever see interoperable RMD products. Cheers Bob >Best Regards, >Georgios > > >On 11/18/2005, "Bob Briscoe" wrote: > > >Georgios, Attila, > > > >To be concrete, I'll ask the question I started with again. Why don't the > >changes to RSVP and NSIS (that I repeat below) resolve the conflict between > >end-to-end and edge-to-edge semantics? The conflict only occurs for flows > >within a signalled reservation, so the conflict can be resolved in the > >signalling. If the conflict is resolved, this proposal should satisfy > >Sally's requirements for specifying alternate semantics for ECN in an > >edge-edge scenario. > > > >[Sally, I'd also be interested in your view - general rules are fine, but > >particular cases like this test the wording.] > > > >I started the earlier thread with this proposal, but as so often happens, > >the very first reply didn't answer the question, then everyone who joined > >the thread continued to "lose the thread". The archived posting is at: > > > > > >---start repeated text--- > > > >It's really a question of what everyone believes the default semantics of a > >reservation are today: > >a) end-to-end cc is not being used for reserved traffic? > >b) end-to-end cc is being used for reserved traffic? > > > >I believe, pragmatically, it is a). > > > >But perhaps you believe the current default position is (b)? If the > >consensus of the TSVWG or NSIS w-gs is with you not me, we would have to > >define extensions to RSVP and NSIS for the endpoints to flag that they were > >NOT intending to use end-to-end cc. To reduce complexity, I would want the > >default for the API to any new signalling stacks to be REQUIRED to be NO > >end-to-end congestion control required. > > > >Then legacy hosts that want to use end-to-end cc would not need to signal > >anything new. > >And if application writers using reservations said nothing and their > >application was installed on an operating system compliant with the > >signalling extension it would automatically signal that end-to-end cc was > >not being used. App writers who wanted to use end-to-end cc within > >reservations would have to explicitly call the API to say so. > >---end repeated text--- > > > >As I also said in the original posting (and we said in our draft), it's > >only worth making this change to RSVP (and NSIS) if there is any hope of it > >ever being necessary. That discussion is still continuing on the lists. > > > > > >Bob > > > >At 05:21 18/11/2005, Sally Floyd wrote: > >>Georgios - > >> > >> >In my opinion, the draft-floyd-ecn-alternates-02.txt could emphasize > >> >which are the requirements that the > >> >edge-to-edge ECN semantics should fulfill such that the > >> >current and future applicability of the (end-to-end) ECN concept > >> >is not limited. > >> > >>I agree. > >> > >>My proposal would be to add the following section to > >>draft-floyd-ecn-alternates-02.txt: > >> > >> "Proposals for Alternate-ECN with Edge-to-Edge Semantics" > >> > >> RFC 3168 specifies the use of the default ECN semantics by an > >> end-to-end transport protocol, with the requirement that "upon the > >> receipt by an ECN-Capable transport of a single CE packet, the > >> congestion control algorithms followed at the end-systems MUST be > >> essentially the same as the congestion control response to a *single* > >> dropped packet" [RFC3168, Section 5]. In contrast, some of the > >> proposals for alternate-ECN semantics are for ECN used in an > >> edge-to-edge context between gateways at the edge of a network > >> region, e.g., for pre-congestion notification for admissions control > >> [BESFC05]. > >> > >> When alternate-ECN is defined with edge-to-edge semantics, this > >> definition needs to ensure that the edge-to-edge semanatics do not > >> conflict with a connection using other ECN semantics end-to-end. > >> One way to avoid conflict would be for the edge-to-edge ECN proposal > >> to include some mechanism to ensure that the edge-to-edge ECN is > >> not used for connections that are using other ECN semantics (standard > >> or otherwise) end-to-end. Alternately, the edge-to-edge semantics > >> could be defined so that they do not conflict with a connection > >> using other ECN semantics end-to-end. > >> > >>Feedback would be welcome. > >> > >>- Sally > >>http://www.icir.org/floyd/ > >> > >>_______________________________________________ > >>tsvwg mailing list > >>tsvwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/tsvwg > > > >____________________________________________________________________________ > >Notice: This contribution is the personal view of the author and does not > >necessarily reflect the technical nor commercial direction of BT plc. > >____________________________________________________________________________ > >Bob Briscoe, Networks Research Centre, BT Research > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 25 05:16:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efacb-0006e1-AE; Fri, 25 Nov 2005 05:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfacY-0006dp-Vd; Fri, 25 Nov 2005 05:15:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06302; Fri, 25 Nov 2005 05:15:17 -0500 (EST) Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efavn-0008C6-9o; Fri, 25 Nov 2005 05:35:52 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id jAPAFUkh017600; Fri, 25 Nov 2005 11:15:40 +0100 (MET) Message-ID: <009001c5f1a9$30888eb0$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Bob Briscoe" References: <5.2.1.1.2.20051124132637.04026108@pop3.jungle.bt.co.uk> Subject: Re: [NSIS] Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it Date: Fri, 25 Nov 2005 11:15:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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: -5.285 () ALL_TRUSTED,AWL,BAYES_00,J_CHICKENPOX_57 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 25 Nov 2005 11:15:46 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Content-Transfer-Encoding: 7bit Cc: philip.eardley@bt.com, tsvwg@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Bob >From your long e-mail I can derive the folowing conclusions: You agree that: * To indicate the need for admission control, it is certainly more convenient to do Diffserv re-marking as RMD does, but in your opinion it is more architecturally consistent to use ECN. * Furthermore in your opinion you agree that you have to be pragmatic and be willing to re-mark the Diffserv codepoint for pre-emption Thus here is a proposal on helping going forward: * Get a consensus on the fact that ECN re-marking and DSCP re-marking are both useful (maybe applied in different settings) and therefore it should be possible that both types of re-marking techniques could be used for edge-to-edge admission control and severe congestion [pre-emption] in an edge-to-edge domain. Do you agree? Best Regards, Georgios ----- Original Message ----- From: "Bob Briscoe" To: "Georgios Karagiannis" Cc: ; ; Sent: Thursday, November 24, 2005 6:40 PM Subject: Re: [NSIS] Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it > Georgios, > > (long e-mail) > > We thought long and hard about which re-marking to use. My primary concern > was to keep the Internet architecture consistent, which leads to the > arguments below. > > 1/ Intended semantics of the Internet Architecture > ================================================== > > 1.1/ Intended re-marking semantics of Diffserv & ECN > -------------------------------------------------- > Diffserv re-marking was defined for two reasons: > i) To allow the ingress of a Diffserv domain to prevent traffic in > excess of the contracted rate/burstiness from being given favourable > treatment at downstream routers if they became congested themselves. > ii) To allow a border router to map the DSCP used for a per-hop > behaviour in the upstream domain to that used for the same PHB in the > downstream domain. > > ECN re-marking is used by a node to indicate that the node itself is > approaching congestion. The intent is to reduce the load from the source, > but marking is forwarded downstream in the expectation that it will be fed > back to the source. > > Thus, the intent of Diffserv re-marking is to alter the downstream per > hop forwarding behaviour if necessary. Diffserv re-marking was not > intended to be fed back to the source. > The intent of ECN re-marking is to reduce the load at source through > feedback. ECN re-marking was specifically not intended to alter the > downstream forwarding behaviour of re-marked packets. > > That's the idealistic view. In practice, it can be convenient to break > architecture. But architecture is there to warn you to think long and hard > when you depart from it, so you are aware of what you might break in the > future. > > 1.2/ Was ECN at the IP layer intended to have end-to-end semantics? > ------------------------------------------------------------------- > RFC3168 was written so that the ECN semantics in IP could be separated > from the end-to-end ECN semantics of TCP when other ECN transports were > defined. > > [According to Sally Floyd at the time, the main reason for specifying ECN > for TCP & IP together in the same RFC was to encourage the first > experiments with ECN to be in TCP implementations which tend to be written > with a lot more care by a few kernel experts.] > > Indeed, Jon Crowcroft and I wrote an I-D reviewing the ECN I-D before it > became RFC3168. In section 12, we proposed text on ECN semantics for > proxies (edge-to-edge), asking that it be added to the ECN RFC: > (Expired) > > Sally Floyd's response (off-line) at the time is quoted here: > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > At 11:35 21/02/01 -0800, Sally Floyd wrote: > >Feedback on Section 12, proposing rules for allowing proxies in the > >network to change ECN codepoints: > > > >I think that this is complicated, and has to be dealt with in a > >separate document, in context. That is, when people have specific > >proposals for intermediate nodes to modify the ECN field, > >then I think they have to be addressed at that time. My own opinion > >is that making general rules ahead of time, in the abstract, > >such as "we will now propose rules for changing the ECN > >capability of a packet at intermediate nodes", never gets it right. > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > is exactly that. A separate > document about the semantics of ECN proxies, in this case with a flow > signalling transport like RSVP (or NSIS). > > The idea of RMD and of is for > the node at the end of a long signalling 'hop' (a whole Diffserv region) > to see how much congestion has accumulated since the start of the region. > Potentially there may be other signalling 'hops' further downstream using > the same technique again. So the egress of one signalling hop must tidy > things up by folding any re-marked packets back in to the same marking as > un-re-marked packets, to avoid confusing further region(s) downstream if > they are using the same technique. > > [For instance, you are thinking of RMD being used for admission control > across a radio access network. But there may be another RAN at the other > end of the network using the same technique. So you must ensure any > re-marked DSCPs are folded back into the same DSCP as non-re-marked > packets at the RMD egress. ] > > 1.3/ Summary of architectural concerns > -------------------------------------- > To indicate the need for admission control, it is certainly more > convenient to do Diffserv re-marking as RMD does, but I believe it is more > architecturally consistent to use ECN re-marking, as we do. > > However, architecture is like religion. You can break it, if it becomes > too inconvenient, and if you can convince enough people you have a good > excuse. > > 2. Practical issues > ------------------- > I don't think we need to break the architecture in this case (which is why > we use ECN), but using ECN re-marking edge-edge does raise the following > issue... > > 2.1/ Edge-to-edge ECN conflicts with end-to-end ECN > --------------------------------------------------- > We fully understand that use of ECN re-marking to trigger admission > control within Diffserv regions would conflict with end-to-end ECN > congestion control for the *same* flow. But we deliberately chose to > specify the end to end service we were providing as "controlled load > [RFC2211]" to try to preclude such cases. > > RFC 2211 says: > > " ... > 2. End-to-End Behavior > ... Should the client's traffic > generation properties fall outside of the region described by the > TSpec parameters, the QoS provided to the client may exhibit > characteristics indicative of overload, including large numbers of > delayed or dropped packets. > > ... > > 7. Policing > ... the network element MUST attempt > to forward the excess traffic on a best-effort basis if sufficient > resources are available > > ... > > Beyond requirements 2 and 3 above, the controlled-load service does > not define the QoS behavior delivered to flows with non-conformant > arriving traffic. Specifically, it is permissible either to degrade > the service delivered to all of the flow's packets equally, or to > sort the flow's packets into a conformant set and a nonconformant set > and deliver different levels of service to the two sets. > > ... > > 9. Guidelines for Implementors > > ... > If most controlled-load traffic arises from rate-adaptive > realtime or elastic applications attempting to establish a bounded > minimum level of service, the use of separate resource classes might > be preferable. > > " > I won't paste everything RF2211 says on with advice for implementors on > scheduling elastic flows with a bounded minimum, as there's rather a lot. > But basically, you get unavoidably bad re-ordering and other complications > that make it hard. Even though this seems a desirable service, it's > unlikely to work well in practice. > > 2.2/ End-to-end ECN conflicts with edge-to-edge admission control > ----------------------------------------------------------------- > The congestion-based admission control mechanism used in RMD and in our > would break if a significant > proportion of admitted traffic were adaptive. If congestion on an interior > path were close to the threshold where admission control was needed, > adaptive traffic might temporarily drop well below its minimum bound. More > flows might then be accepted, then the adaptive traffic could grow again, > destroying the controlled load service for all flows through that path. > > [Note: Variable bit rate (VBR) like video traffic would superfically seem > to break a measurement-based admission control system in the same way as > adaptive traffic. But unlike with adaptive traffic, troughs in VBR load > are not correlated with congestion. Our analyses of how the effective > bandwidth of VBR (and silence-suppressed voice) aggregates has shown that > our solution works OK for VBR, given specific conditions on the amount of > aggregation and provided VBR traffic sources are not correlated. We are > currently preparing this analysis for publication.] > > 2.3/ Summary of end/edge conflicts > ---------------------------------- > So, we prefer to say that a different service would have to be requested > to cater for your hybrid requirement. Hence my preference for explicitly > requesting "adaptive rate control with a bounded minimum" in the > signalling, as a different QoS service. In NSIS terms, this is would be in > the QSPEC, I believe. > > 2.4/ Codepoint space > -------------------- > Real-estate in the IP header is at a premium. Treating the 6-bit Diffserv > field and the 2-bit ECN field separately leads to 2^6 + 2^2 = 68 > codepoints. Treating them together leads to 2^8 = 256 codepoints. In the > MPLS EXP field, real-estate is a far greater headache. > > If ECN marking is orthogonal to Diffserv marking for most Diffserv > codepoints, it makes sense to treate the field as 6-bit and 2-bit > sub-fields. But I don't believe we should be averse to bending the rules > to save codepoint space across both fields. > > For instance both our approach and RMD need another marking state for a > router in the Diffserv interior to indicate the need for flow pre-emption > (eg. after re-routes). Pre-emption represents severe congestion and needs > to be fed back upstream. So by my arguments above pre-emption should be > re-marked using the ECN field. But in our current pre-emption solution, if > two or more nodes in a path require some flows to be pre-empted, packets > that have already been re-marked once to indicate pre-emption need to be > treated differently by downstream nodes. So by my arguments above > pre-emption should also be re-marked using the DSCP. > > Well, it would be silly to waste two codepoints for one state. And there > aren't enough ECN codepoints anyway. So, IMHO, you have to be pragmatic > and be willing to re-mark the Diffserv codepoint for pre-emption (CAVEAT: > the authors of still haven't > reached consensus on marking - that's why > hasn't been updated yet). > > 7/ Consistent meaning of an ECN marking > --------------------------------------- > I hope I have answered your question about why we use ECN not Diffserv > re-marking. We are not completely inflexible about using ECN, but I do > have further reasons for preferring ECN re-marking---to do with the > economic interpretation of congestion marking across different classes. It > would take too long to go into that here, but you can read a recent paper > I published on the subject if interested. > > Commercial Models for IP Quality of Service Interconnect, Bob Briscoe & > Steve Rudkin (BT), in BTTJ Special Edition on IP Quality of Service, 23(2) > (Apr 2005) > > > I have also given responses inline... > > > At 09:28 24/11/2005, Georgios Karagiannis wrote: >>----- Original Message ----- From: >>To: ; >>Cc: ; >>Sent: Thursday, November 24, 2005 1:23 AM >>Subject: RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP >>re-markingcan do it >> >> >>>>>[GK] What is the technical reason of using ECN for edge-toedge >>>>>congestion control? >>>[PE] The use of Ecn seems natural to me, since we wnat the network to >>>indicate incipient congestion and that's what ECN is supposed to do. Note >>>that the semantics are the same as rfc3168 (ECN) - ie same codepoints of >>>ECN field and CE codepoint indicates incipient congestion. I also think >>>it can help with migration to a fully ecn world. As operators get >>>experience of using ecn, whilst not requiring all nws / end hosts to be >>>using it. >> >>Georgios: yes I understand but the ECN semantics apply end-to-end, not >>edge-toedge, >>please see the previous discussions on this issue! > > [BB] ECN semantics were originally defined for an end-to-end protocol > (TCP). That does not imply they were only intended to ever be end-to-end. > RFC3168 did not preclude edge-to-edge. And at least one of the authors > believed edge-to-edge semantics could be a valid thing to define later > (see quote from Sally Floyd above). > > > >>>[PE] Second, using DSCP re-marking seems to need a lot of DSCPs. >>>According to your draft, admission control implies 2 per traffic class >>>(one for re-marked pkts, one for other pkts passing thru the same >>>router). Plus another for the severe congestion indication. In addition, >>>in the core network an interesting future extension is to use the >>>mechanisms in a network with MPLS-TE (see our framework draft for brief >>>discussion) - there isnt sufficient space in the label for these extra >>>dscps. >> >>Georgios: regarding the number of DSCP's you are right, but there are ways >>of reducing this number, please see the RMD draft. >>Please also note that the streaming aplication example that has been >>discussed in >>the tsvwg and nsis mailing lists shows that it is usefull to use >>end-to-end ECN based congestion control for reserved traffic. >>This streaming application example can very efficiently use RSVP and the >>DCCP protocol (which uses the end-to-end ECN concept). > > [BB] No-one on the list has said it would be efficient. In fact the > opposite has been said (by Louise Burness) and no-one has disagreed. I > believe this hybrid service should be set aside for someone else to define > a mechanism for later. Intserv couldn't even do it very well, even though > it had a per-flow scheduler. > > >>[GK] Please also note that the support of this type of this type of >>streaming application that >>combines the end to end ECN semantics >>with reserved minimum bandwidth is needed not only >>in the backbone network but also in the wireless network as well. >>Therefore the rate-adaptation function of ECN (DCCP functionality) >>combined with minimum bandwidth reservation can be very important. > > [BB] Yes, an adaptive application with a minimum rate would be a desirable > service. But it's not the one we are defining. And you will find it > doesn't work with RMD's congestion-based admission scheme either. > > [BB] We are trying to do Controlled Load to scale to the Internet. We > don't know how to implement this hybrid at Internet scale. We have had to > limit our scope to avoid this hybrid problem. And you will find that such > a hybrid service wouldn't work with the mechanism you have defined for RMD > either. > > [BB] So I need to turn your question back on you: how would you prevent > adaptive applications using your RMD congestion mechanism, and breaking > the admission control system? > > [BB] The solution I have proposed is to require the application to signal > this hybrid requirement and if it is not signalled, to drop any excess > traffic at the region ingress in order to disincentivise any adaptive > application trying to use the wrong service for its needs. > > >>>Third, (as bob has pointed out) that it's easy to overcome the end-to-end >>>vs edge-to-edge >>marking issue (if that's really needed, which I'm inclined to think it >>isnt) >> >>Georgios: regarding this point I am not sure if it is easy! It depends on >>the >>imposed additional complexity. > > [BB] If a request for this hybrid were signalled (and an operator chose to > support the hybrid service), with the current state of knowledge, I would > say that this hybrid traffic would have to be dealt with by a less > scalable means, such as Intserv per-flow schedulers on every node, or your > hop by hop reservation method in RMD. > > > Bob > >>Best regards, >>Georgios >> >> >>> >>>________________________________ >>> >>>From: tsvwg-bounces@ietf.org on behalf of philip.eardley@bt.com >>>Sent: Wed 23/11/2005 23:48 >>>To: karagian@cs.utwente.nl >>>Cc: tsvwg@ietf.org; nsis@ietf.org >>>Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP >>>re-markingcan do it >>> >>> >>> >>>some comments below. >>> >>>best wishes, phil >>> >>>________________________________ >>> >>>* To: >>> > >>>* Subject: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP >>>re-marking can do it >>>* From: "Georgios Karagiannis" >> > >>>* Date: Mon, 21 Nov 2005 10:52:22 +0100 >>>* Cc: tsvwg at ietf.org , nsis at >>>ietf.org >>> >>>Hi Bob >>> >>>In addition to the previous discussion I would like to >>>discuss and ask you the following. >>> >>>[chop] >>>What is the technical reason of using ECN for edge-toedge congestion >>>control, >>>when the same solution (on providing admission control >>>based on congestion notification and severe >>>congestion [pre-emption]) can be provided by using DSCP re-marking? >>> >>> >>> >>> >>>_______________________________________________ >>>tsvwg mailing list >>>tsvwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/tsvwg >>> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis > > ____________________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 25 12:40:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhYh-0002C1-4o; Fri, 25 Nov 2005 12:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfhYg-0002Bw-H9 for nsis@megatron.ietf.org; Fri, 25 Nov 2005 12:40:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23353 for ; Fri, 25 Nov 2005 12:39:44 -0500 (EST) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Efhry-0007Fq-AJ for nsis@ietf.org; Fri, 25 Nov 2005 13:00:23 -0500 Received: (qmail invoked by alias); 25 Nov 2005 17:40:09 -0000 Received: from p54A33EF9.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.62.249] by mail.gmx.net (mp030) with SMTP; 25 Nov 2005 18:40:09 +0100 X-Authenticated: #4469397 From: Thomas Herzog To: nsis@ietf.org, "Hancock, Robert" Date: Fri, 25 Nov 2005 18:35:19 +0100 User-Agent: KMail/1.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511251835.19771.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Subject: [NSIS] GIST Late State Insallation: Does Responding NSLP wait for NetworkNotification? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, I am currently in the phase of testing and validating our GIST implementation, for which I am able to use the GistPing tool of the folks from Goettingen which currently proves to work just fine as a lightweight testing NSLP. So far, I am now facing the task of validating our Late State Installation mechanism, so a thought occured to me: Does the Responding Node's NSLP have to wait for a NetworkNotification after having told GIST to establish backwards routing state until it sends back messages itself? I see the problem in using Late State Installation in the case, the RN NSLP wants to directly answer to a received incoming Message. GIST discards any information about the Flow after having sent the response, thus a SendMessage from the Responding NSLP prior to the final State Setup would lead to an upstream Query to be sent. This would be a severe problem. So I think the Responding Node's NSLP should wait after receiving/answering the initial RecvMessage for the NetworkNotification which tells it that state is set up! Has this been covered in the NSLP draft? Currently (draft-08), we are signaling "Route changed, status XY" and "Last Node" via NetworkNotifications. I think, this should be extended by "Route initially set up", because in this case, there is no Route changed and the information that the messaging path is available should be also vital to a NSLP? Can someone clarify this? Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 28 13:17:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgnZO-0001Vp-HR; Mon, 28 Nov 2005 13:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgnZN-0001VV-2M for nsis@megatron.ietf.org; Mon, 28 Nov 2005 13:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12661 for ; Mon, 28 Nov 2005 13:16:57 -0500 (EST) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgntF-0008Jd-TK for nsis@ietf.org; Mon, 28 Nov 2005 13:38:15 -0500 Received: (qmail invoked by alias); 28 Nov 2005 18:17:17 -0000 Received: from p54A307DA.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.7.218] by mail.gmx.net (mp019) with SMTP; 28 Nov 2005 19:17:17 +0100 X-Authenticated: #4469397 From: Thomas Herzog To: "Hancock, Robert" , "Bless, Roland" Date: Mon, 28 Nov 2005 19:12:22 +0100 User-Agent: KMail/1.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511281912.23057.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: [NSIS] GIST Refresh Mechanism eventually breaks upstream path on Crossover Router X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, all, I think there is a glitch in GIST refresh mechanism in the case that rerouting takes place. If rerouting occurs, the new and the old GIST signaling paths should converge somewhere again, let us call this node "Crossover Router". This Crossover Router has a "former upstream peer" and a "current upstream peer", that means, the current upstream peer is on the new Signaling Path and has just established a connection to the Crossover Router. The Crossover Router stored upstream routing information for that flow to go over the current upstream peer. GIST Routing State on the former upstream peer however is subject to a soft-state mechanism and will stay established until it's RSV time timeout occurs or the NSLP pulls down the Routing State manually via "InvalidateRoutingState". Having noted this, it may happen that the former upstream peer triggers a Refresh of the routing state. The Refresh would cause the Crossover Router to install the former upstream peer for the upstream path. Also, the Crossover Router would again signal a Routing Change to it's NSLP. The next refresh from the current upstream peer will again set back the upstream path and so on and so on as long as the state on the former upstream peer is valid. One could now define that the NSLP on the crossover router should actively tell the NSLP on the former upstream peer to pull down GIST state. But even if this would be done, the Refresh could already be triggered before the NSLP has done this and the NSLP gets again a new "Routing changed" notification. Also, one could argue, that design problems in GIST should not have to be mended by active intervention by the NSLP. And the eventual loss of correct upstream path anywhere on the Signaling path should be considered a "design problem". Having thought about this issue, I would like to propose discussion about a new GIST Query-type Message, say "GIST Refresh" with the following semantics: GIST Refresh: - may refresh established Routing State - may lead to establishment of new Routing State GIST Query: - may replace established Routing State - may lead to establishment of new Routing State Thus the former upstream peer would try a Refresh, this fails and the Routing State gets deleted without any Interaction needed by NSLP. I know, this would be a big modification to GIST, but it would make GIST work more reliable in case of rerouting. Cheers, Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 28 16:33:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqdF-0005ES-Ui; Mon, 28 Nov 2005 16:33:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqdE-0005E9-Qr for nsis@megatron.ietf.org; Mon, 28 Nov 2005 16:33:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21081 for ; Mon, 28 Nov 2005 16:33:07 -0500 (EST) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Egqx5-0003vi-En for nsis@ietf.org; Mon, 28 Nov 2005 16:54:26 -0500 Received: (qmail invoked by alias); 28 Nov 2005 21:33:33 -0000 Received: from p54A307DA.dip0.t-ipconnect.de (EHLO [192.168.0.3]) [84.163.7.218] by mail.gmx.net (mp034) with SMTP; 28 Nov 2005 22:33:33 +0100 X-Authenticated: #4469397 From: Thomas Herzog To: nsis@ietf.org Subject: Re: [NSIS] GIST Refresh Mechanism eventually breaks upstream path on Crossover Router Date: Mon, 28 Nov 2005 22:28:41 +0100 User-Agent: KMail/1.9 References: <200511281912.23057.thomas.herzog@gmx.li> In-Reply-To: <200511281912.23057.thomas.herzog@gmx.li> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511282228.41233.thomas.herzog@gmx.li> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, all, of course, there could also be other possibilities to fix this issue. I think, in general, a Responding Node should be able to detect whether an incoming GIST Query is part of a state setup or of a refresh requence. This could also be implemented by adding a flag *somewhere* to a Query. So a Responding Node could drop a Query if it comes in from another peer than the currently installed peer and is part of a Refresh. Cheers, Thomas Am Montag, 28. November 2005 19:12 schrieb Thomas Herzog: > Having thought about this issue, I would like to propose discussion about a > new GIST Query-type Message, say "GIST Refresh" with the following semantics: > > GIST Refresh: > - may refresh established Routing State > - may lead to establishment of new Routing State > > GIST Query: > - may replace established Routing State > - may lead to establishment of new Routing State _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Nov 29 11:15:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh88l-0004IY-VW; Tue, 29 Nov 2005 11:15:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh88k-0004Fn-NT for nsis@megatron.ietf.org; Tue, 29 Nov 2005 11:15:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26500 for ; Tue, 29 Nov 2005 11:14:49 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+CHpwRLsHWV8ZLX+An+N1WjoK4rp43lfo=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh8Sq-000108-B8 for nsis@ietf.org; Tue, 29 Nov 2005 11:36:21 -0500 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 1Eh88J-0006ob-DV; Tue, 29 Nov 2005 17:15:19 +0100 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 390FDB4B4; Tue, 29 Nov 2005 17:15:07 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Eh88I-0005Ai-LC; Tue, 29 Nov 2005 17:15:06 +0100 Message-ID: <438C7E8A.4060400@tm.uka.de> Date: Tue, 29 Nov 2005 17:15:06 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "nsis@ietf.org" , "Hancock, Robert" X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.3 (----) 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.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [NSIS] GIST API: Adding SessionID to NetworkNotification, SetStateLifetime, InvalidateRoutingState? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, our implementation experience suggests that it might be a good thing to add the SessionID to the above API calls. So in case GIST wants to issue a NetworkNotification to an NSLP, this NSLP has no idea to which session the flow belongs. GIST should have that information anyway. In the other direction (SetStateLifetime, InvalidateRoutingState) GIST must loop over all sessions. Any objections? Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis