From architecture-discuss-bounces@ietf.org Thu Jan 04 16:58:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aaE-00036w-3j; Thu, 04 Jan 2007 16:57:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aaC-00036m-QY for architecture-discuss@ietf.org; Thu, 04 Jan 2007 16:57:08 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aaB-0005HB-6X for architecture-discuss@ietf.org; Thu, 04 Jan 2007 16:57:08 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 80E0C56414; Thu, 4 Jan 2007 16:56:59 -0500 (EST) Date: Thu, 4 Jan 2007 16:56:59 -0500 From: John Leslie To: Pekka Nikander Message-ID: <20070104215659.GB21605@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <20061219174742.GN2478@verdi> <20061227154647.GA2859@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: architecture-discuss@ietf.org Subject: [arch-d] Mobility Responsibilities X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka Nikander wrote: > To: John Leslie > >> Regardless, I'd be really surprised if _nobody_ has a wishlist >> concerning mobility, security, and/or privacy. It would be really >> helpful if we gathered these wishlists within the next week... > > A. Mobility functionality we may need on almost all "layers": > > 1. physical layer looks like the best layer for handling local, fast, > radio based mobility (MIMO etc) > > 2. link layer looks like the best layer for handling local, cross > link or cross base station mobility Let's not worry about the division between these two layers. > 3-4. internetworking and/or transport looks like the natural layer > for global host mobility; there are weak indications (signalling > efficiency, aggregation etc) indicating that internetworking is > probably better I'll get back to this... > 5. personally, I still don't understand all the subtleties related to > session mobility, especially inter-node session handovers, and e2e > error correction and congestion control state Nor do I... But I suggest trying to pack most congestion managment into the Transport layer. > 7. if we had proper application naming aggregation structures, we > could most probably handle subnet mobility and application-level > delegation much better than today It doesn't seem helpful to me to treat application mobility as the same animal -- It seems more like load-sharing than mobility, and it doesn't seem to require coordination between server and client ends. Getting back to Internetting / Transport: Global Host Mobility means to me: - nodes (much like laptops) will change their physical location; - there will be periods when no bidirectional path is working; - we cannot always know what network they will connect to next; - we can assume one end (or a midpoint) has stable connectivity; I would guess we want: - endpoints to find each other within a few round-trip times; - sessions to continue after a break and reconnect; - details of the topology change invisible to applications; Are these statements correct? Are they complete? Responsibilities I see for Internetworking layer are: - loop-free routes should be found to any reachable locator; - it should be possible to signal congestion to the sender; - it should be possible to "punish" senders that don't throttle the traffic sent when congestion is signaled; Pekka seems to want an additional responsibility: - an alternate path should be found when one path fails. I tend to disagree, because: - ideally, the congestion level which equals failure should be configured at a higher level (not constant for all sessions); - both the old and the new paths would need to be loop-free; - I'm not sure congestion signalling can be kept straight; So I tentatively assign that to the Transport layer... Responsibilities I see for Transport layer are: - the rate of sending should be reduced if congestion is seen; - the other end should be notified of alternate locators; - dropped packets should be detected and retransmitted; - at some congestion level an alternate locator should be tried; - duplicate packets should be detected and eliminated; - traffic should migrate to the least congested locator; How does this look? -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Jan 04 17:14:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2arE-0000u4-4n; Thu, 04 Jan 2007 17:14:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2arC-0000tv-4Z for architecture-discuss@ietf.org; Thu, 04 Jan 2007 17:14:42 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2arA-00088g-Tz for architecture-discuss@ietf.org; Thu, 04 Jan 2007 17:14:42 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 2DCA356414; Thu, 4 Jan 2007 17:14:41 -0500 (EST) Date: Thu, 4 Jan 2007 17:14:40 -0500 From: John Leslie To: Pekka Nikander Message-ID: <20070104221440.GC21605@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <20061219174742.GN2478@verdi> <20061227154647.GA2859@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: architecture-discuss@ietf.org Subject: [arch-d] Security and Privacy X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka Nikander wrote: > > B. Different security functions we will need on almost all "layers": > > 1. physical layer is a great place to implement geographic location > security and over-the-air opportunistic encryption, etc. I don't see what good this info will do there... > 2. link layer is a good place to include network access control I didn't envision any changes here. > 3-4. there are indications that the location of IPsec, i.e., between > traditional internetworking and traditional transport, is a good > choice for placing e2e encryption and integrity I tend to agree; but I don't feel able to state your intent as desires and responsibilities. > 7. it is cumbersome to place user and service authentication and > access control outside of the application layer, as they have their > application specific aspects There is, however, a tendency to rely on lower-level info. I'm not sure whether this calls for any new responsibilities... > C. It is impossible to properly implement privacy without considering > all "layers" simultaneously > > 1-7. just consider session tracking and mobility I was expecting some desires re: difficulty to backtrack from ULID to personal info. We could in principle make this arbitrarily hard... -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Jan 07 18:43:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3he8-0002Wc-Si; Sun, 07 Jan 2007 18:41:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3he7-0002WX-NT for architecture-discuss@ietf.org; Sun, 07 Jan 2007 18:41:47 -0500 Received: from montage.altserver.com ([72.34.52.22] helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3he5-00053h-K4 for architecture-discuss@ietf.org; Sun, 07 Jan 2007 18:41:47 -0500 Received: from i03m-212-195-38-17.d4.club-internet.fr ([212.195.38.17] helo=asus) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1H3he1-0007Wq-R0 for architecture-discuss@ietf.org; Sun, 07 Jan 2007 15:41:42 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Jan 2007 00:41:42 +0100 To: architecture-discuss@ietf.org From: Michel Gauthier In-Reply-To: <623826.82279.qm@web31802.mail.mud.yahoo.com> References: <816DD9299957E547B5D758D7F977D6DC01178F72@tayexc14.americas.cpqcorp.net> <623826.82279.qm@web31802.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-7A4D60C6; boundary="=======AVGMAIL-45A185367D22=======" X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - telepresse.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Subject: [arch-d] common synthesis X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --=======AVGMAIL-45A185367D22======= Content-Type: multipart/alternative; boundary="=====================_51436078==.ALT"; x-avg-checked=avg-ok-7A4D60C6 --=====================_51436078==.ALT Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7A4D60C6 I prepare for Telepresse an intelligence report on the problem that has been identified by the IAB, and that is discussed by this mailing list, the solutions that it investigates for the Internet's future architecture, and its consequences. I would like to check with you about the main ideas that we extracted from this debate (we analysed the _key_ ideas for decision makers emerging from your active brainstorming). I also hope that my questions might help a common synthesis at this stage. 1. there is an over-complexity problem resulting from the size of the network. It is reflected in the size of the IPv6 address, the increasing use of multihoming, the BGP protocol instability, and the level of intelligence required from routers. Fred Baker provided some stunning examples making the problem still more difficult in real life. The IAB released a Draft on the issue. 2. there are three proposed attitudes: - a general attitude favouring band-aids for the 10 to 20 years to come, and a new architecture further on. Due to the urgency, it prefers delaying the analysis of the problem (as it takes too long), and prefers to start a rough consensus solution now. - JFC Morfin thinks that over-complexity is a stable new situation, and that it must be analysed and addressed with dedicated architectural concepts (distributed autonomy and subsidiarity) in turn completing RFC 1958 by Brian Carpenter, and RFC 3439 by Randy Bush and David Meyer. - Noel Chiappa, Pekka Nikander, Jim Bound, and John Day are looking at the longer term. John Day and JFC Morfin advocate a network operating system as cement for the possibly differing and time scaled solutions. 3. There are three possible options: one lead by Noel Chiappa/Pekka Nikander that is now at a near partial consensus, ad two other ones quoted by JFC Morfin. - IPv8: nobody wants it. It consists in keeping IPv4 addresses for NATs only, and adding NAT managed subaddressing. This solution would/will self deploy due to the expected increase of the price of IPv4 addresses. - IPv6: the IPv6 address space in IPv6 headers using IPv6 ITU /3 would be understood as a container for four orthogonal elements: header, routing, global identification, local extension. In addition routing management could be removed from the network and supervised at the edge as a multi-value added service extension of the DNS, basedon situation reports from en-route switchers. - Jack-up (?): it consists in adding a routing namespace with different possible solutions, which are not fully clarified yet. It is the most debated proposition. One of its main points is to address GNP issues. HIP and SHIM6 seem to be the experience behind that solution. Can it be qualified as an "MLPS6" approach? There is thus far no complete description of the proposed idea, but a Draft could be written soon by its promoters. All this raises some questions: A. what are the risks involved in the IPv8 solution developing - it seems that some organisations may already use variations of it? How to block it, or to make it acceptable if it is unavoidable? Could someone want to seriously document it and its cons/pros as a Draft? B. what is the difference between the IPv6 and Jack-up proposition? Jack-up is about two structural name spaces (IPv6 + a totally new one?). IPv6 is about immediate support of three orthogonal namespaces at the edges without real change, where only one structured one is currently supported? C. the "jack-up" approach seems too complex to introduce, unless a good transition strategy is adopted. What would that strategy be? Who would conduct it? Why would it be faster than the one used to promote IPv6 during the last 14 years? D. The time scale is: - IPv8 is actually here already, but just not documented, - IPv6 is here, but would need the ITU to document its use of an IPv6 /3 to support it. No indication is given about a scenario for the jack-up proposition? It would require a WG to be created. It would produce different Drafts about the context, proposition, and transitioning. Then, industry should start developing applications, and test them. ISP and exchanges should subsequently start implementing them, and carrying out their own market tests. How many years would this represent? E. Only JFC Morfin seems to insist on the routing path to be controlled by the sending end (upon receiving end data) and other routing added value services to users. It seems that the list only considers the network needs and not the user needs? He also seems the only one to call for a DDDS approach of the routing computation? F. The US DoD has adopted IPv6 as per http://whitehouse.gov/pcipb. Several Telecos, including BT in England, are committed to MLPS for telephone services. China is expected to be rapidly a large user of IPv6 (or to study its own IPv10 hoax(?)/project(?)). The ITU development of NGN is supposed to be supported by IPv6. Moreover, the GENI test bed as well. Can these deployments, experimentations, and projects be affected by the problem that you are currently investigating? In particular, could the US Defense Department meet with congestion or technology follow-up problems? We therefore understand that this topic is vital for the e-economy of the USA, Europe, China, and India and will report it as such. I thank you for your time, attention, and help. Michel Gauthier. mg@telepresse.com ----- All advice, leads, and clarifications are welcome. If you have any information or private comments, please do not hesitate to send them directly to Telepresse. Telepresse Intelligence Reports are tailor-made and strictly confidential. Sources are never disclosed. They are commissioned and intended for participating freelancers, press agencies, corporate documentalists, and political analysts. They are constantly updated. They may be written in French, Spanish, English, or Japanese. Telepresse is a closed group of coopted managers and journalists that practise mutual information and documentation sharing. Telepresse does not offer external commercial or private service. ----- --=====================_51436078==.ALT Content-Type: text/html; charset=us-ascii; x-avg-checked=avg-ok-7A4D60C6 I prepare for Telepresse an intelligence report on the problem that has been identified by the IAB, and that is discussed by this mailing list, the solutions that it investigates for the Internet’s future architecture, and its consequences. I would like to check with you about the main ideas that we extracted from this debate (we analysed the _key_ ideas for decision makers emerging from your active brainstorming). I also hope that my questions might help a common synthesis at this stage.

1. there is an over-complexity problem resulting from the size of the network. It is reflected in the size of the IPv6 address, the increasing use of multihoming, the BGP protocol instability, and the level of intelligence required from routers. Fred Baker provided some stunning examples making the problem still more difficult in real life. The IAB released a Draft on the issue.

2. there are three proposed attitudes:

- a general attitude favouring band-aids for the 10 to 20 years to come, and a new architecture further on. Due to the urgency, it prefers delaying the analysis of the problem (as it takes too long), and prefers to start a rough consensus solution now.

- JFC Morfin thinks that over-complexity is a stable new situation, and that it must be analysed and addressed with dedicated architectural concepts (distributed autonomy and subsidiarity) in turn completing RFC 1958 by Brian Carpenter, and RFC 3439 by Randy Bush and David Meyer.

- Noel Chiappa, Pekka Nikander, Jim Bound, and John Day are looking at the longer term. John Day and JFC Morfin advocate a network operating system as cement for the possibly differing and time scaled solutions.

3. There are three possible options: one lead by Noel Chiappa/Pekka Nikander that is now at a near partial consensus, ad two other ones quoted by JFC Morfin.

- IPv8: nobody wants it. It consists in keeping IPv4 addresses for NATs only, and adding NAT managed subaddressing. This solution would/will self deploy due to the expected increase of the price of IPv4 addresses.

- IPv6: the IPv6 address space in IPv6 headers using IPv6 ITU /3 would be understood as a container for four orthogonal elements: header, routing, global identification, local extension. In addition routing management could be removed from the network and supervised at the edge as a multi-value added service extension of the DNS, basedon situation reports from en-route switchers.

- Jack-up (?): it consists in adding a routing namespace with different possible solutions, which are not fully clarified yet. It is the most debated proposition. One of its main points is to address GNP issues. HIP and SHIM6 seem to be the experience behind that solution. Can it be qualified as an "MLPS6" approach? There is thus far no complete description of the proposed idea, but a Draft could be written soon by its promoters.

All this raises some questions:

A. what are the risks involved in the IPv8 solution developing - it seems that some organisations may already use variations of it? How to block it, or to make it acceptable if it is unavoidable? Could someone want to seriously document it and its cons/pros as a Draft?

B. what is the difference between the IPv6 and Jack-up proposition? Jack-up is about two structural name spaces (IPv6 + a totally new one?). IPv6 is about immediate support of three orthogonal namespaces at the edges without real change, where only one structured one is currently supported?

C. the "jack-up" approach seems too complex to introduce, unless a good transition strategy is adopted. What would that strategy be? Who would conduct it? Why would it be faster than the one used to promote IPv6 during the last 14 years?

D. The time scale is:
- IPv8 is actually here already, but just not documented,
- IPv6 is here, but would need the ITU to document its use of an IPv6 /3 to support it.
No indication is given about a scenario for the jack-up proposition? It would require a WG to be created. It would produce different Drafts about the context, proposition, and transitioning. Then, industry should start developing applications, and test them. ISP and exchanges should subsequently start implementing them, and carrying out their own market tests. How many years would this represent?

E. Only JFC Morfin seems to insist on the routing path to be controlled by the sending end (upon receiving end data) and other routing added value services to users. It seems that the list only considers the network needs and not the user needs? He also seems the only one to call for a DDDS approach of the routing computation?

F. The US DoD has adopted IPv6 as per http://whitehouse.gov/pcipb . Several Telecos, including BT in England, are committed to MLPS for telephone services. China is expected to be rapidly a large user of IPv6 (or to study its own IPv10 hoax(?)/project(?)). The ITU development of NGN is supposed to be supported by IPv6. Moreover, the GENI test bed as well. Can these deployments, experimentations, and projects be affected by the problem that you are currently investigating? In particular, could the US Defense Department meet with congestion or technology follow-up problems? We therefore understand that this topic is vital for the e-economy of the USA, Europe, China, and India and will report it as such.

I thank you for your time, attention, and help.

Michel Gauthier.
mg@telepresse.com
-----
All advice, leads, and clarifications are welcome. If you have any information or private comments, please do not hesitate to send them directly to Telepresse. Telepresse Intelligence Reports are tailor-made and strictly confidential. Sources are never disclosed. They are commissioned and intended for participating freelancers, press agencies, corporate documentalists, and political analysts. They are constantly updated. They may be written in French, Spanish, English, or Japanese. Telepresse is a closed group of coopted managers and journalists that practise mutual information and documentation sharing. Telepresse does not offer external commercial or private service.
-----
 --=====================_51436078==.ALT-- --=======AVGMAIL-45A185367D22======= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=======AVGMAIL-45A185367D22=======-- From architecture-discuss-bounces@ietf.org Mon Jan 08 09:35:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3vZO-0001SE-Cb; Mon, 08 Jan 2007 09:33:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3vZN-0001S7-Hg for architecture-discuss@ietf.org; Mon, 08 Jan 2007 09:33:49 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3vZK-0001KC-KN for architecture-discuss@ietf.org; Mon, 08 Jan 2007 09:33:49 -0500 Received: from pc6 (1Cust123.tnt27.lnd4.gbr.da.uu.net [62.188.154.123]) by galaxy.systems.pipex.net (Postfix) with SMTP id 768D6E0002CB; Mon, 8 Jan 2007 14:33:39 +0000 (GMT) Message-ID: <003d01c73329$80db9b60$0601a8c0@pc6> From: "tom.petch" To: , "Michel Gauthier" References: <816DD9299957E547B5D758D7F977D6DC01178F72@tayexc14.americas.cpqcorp.net><623826.82279.qm@web31802.mail.mud.yahoo.com> Subject: Re: [arch-d] common synthesis Date: Mon, 8 Jan 2007 10:41:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I disagree that this is a fair summary; I think that there are other points that have been referred to along the way that may turn out to be more significant in the long term. a) Most of the network developments in the past have been driven by domestic voice (not data, not business). Statistics show that data traffic has/is/is about to exceed voice but I still believe that the network of ten years hence will be shaped by a billion or two mobile phone users in India/China/Japan ... and that this will be based on IPvn (n GE 6). I do not understand the nature of the latest voice technology to understand where this is taking us. b) voice more than other applications needs QOS (COS/TOS a generic term for prioritisation of delay/availability/loss/etc sensitive traffic) which is happening, but slowly, with IPv4 etc. c) the current Internet suits the ISP who often give their customers a bad service but to whom the technology locks them in. Voice mobile users chop and change contracts to match requirements. With IPv4 routing this is difficult or impossible since the ISP (mostly) controls the PA addressing and PI addressing will blow the capacity of some key routers. Note that DNS does work in giving users who want it the choice to escape the control of ISP where names are concerned; a better directory service, mapping name to current locator, is another option in this area. Locator/identifier split has of course loomed large on a number of ietf lists. d) A related need is for multiple parallel links/paths, to the same or different ISP to provide incremental increases in capacity/resilience in contrast to the IPvn approach which focusses on providing one best path (where best is not good enough:-( This must be transparent to the application. Tom Petch ----- Original Message ----- From: "Michel Gauthier" To: Sent: Monday, January 08, 2007 12:41 AM Subject: [arch-d] common synthesis > I prepare for Telepresse an intelligence report on the problem that > has been identified by the IAB, and that is discussed by this mailing > list, the solutions that it investigates for the Internet's future > architecture, and its consequences. I would like to check with you > about the main ideas that we extracted from this debate (we analysed > the _key_ ideas for decision makers emerging from your active > brainstorming). I also hope that my questions might help a common > synthesis at this stage. > > 1. there is an over-complexity problem resulting from the size of the > network. It is reflected in the size of the IPv6 address, the > increasing use of multihoming, the BGP protocol instability, and the > level of intelligence required from routers. Fred Baker provided some > stunning examples making the problem still more difficult in real > life. The IAB released a Draft on the issue. > > 2. there are three proposed attitudes: > > - a general attitude favouring band-aids for the 10 to 20 years to > come, and a new architecture further on. Due to the urgency, it > prefers delaying the analysis of the problem (as it takes too long), > and prefers to start a rough consensus solution now. > > - JFC Morfin thinks that over-complexity is a stable new situation, > and that it must be analysed and addressed with dedicated > architectural concepts (distributed autonomy and subsidiarity) in > turn completing RFC 1958 by Brian Carpenter, and RFC 3439 by Randy > Bush and David Meyer. > > - Noel Chiappa, Pekka Nikander, Jim Bound, and John Day are looking > at the longer term. John Day and JFC Morfin advocate a network > operating system as cement for the possibly differing and time scaled > solutions. > > 3. There are three possible options: one lead by Noel Chiappa/Pekka > Nikander that is now at a near partial consensus, ad two other ones > quoted by JFC Morfin. > > - IPv8: nobody wants it. It consists in keeping IPv4 addresses for > NATs only, and adding NAT managed subaddressing. This solution > would/will self deploy due to the expected increase of the price of > IPv4 addresses. > > - IPv6: the IPv6 address space in IPv6 headers using IPv6 ITU /3 > would be understood as a container for four orthogonal elements: > header, routing, global identification, local extension. In addition > routing management could be removed from the network and supervised > at the edge as a multi-value added service extension of the DNS, > basedon situation reports from en-route switchers. > > - Jack-up (?): it consists in adding a routing namespace with > different possible solutions, which are not fully clarified yet. It > is the most debated proposition. One of its main points is to address > GNP issues. HIP and SHIM6 seem to be the experience behind that > solution. Can it be qualified as an "MLPS6" approach? There is thus > far no complete description of the proposed idea, but a Draft could > be written soon by its promoters. > > All this raises some questions: > > A. what are the risks involved in the IPv8 solution developing - it > seems that some organisations may already use variations of it? How > to block it, or to make it acceptable if it is unavoidable? Could > someone want to seriously document it and its cons/pros as a Draft? > > B. what is the difference between the IPv6 and Jack-up proposition? > Jack-up is about two structural name spaces (IPv6 + a totally new > one?). IPv6 is about immediate support of three orthogonal namespaces > at the edges without real change, where only one structured one is > currently supported? > > C. the "jack-up" approach seems too complex to introduce, unless a > good transition strategy is adopted. What would that strategy be? Who > would conduct it? Why would it be faster than the one used to promote > IPv6 during the last 14 years? > > D. The time scale is: > - IPv8 is actually here already, but just not documented, > - IPv6 is here, but would need the ITU to document its use of an IPv6 > /3 to support it. > No indication is given about a scenario for the jack-up proposition? > It would require a WG to be created. It would produce different > Drafts about the context, proposition, and transitioning. Then, > industry should start developing applications, and test them. ISP and > exchanges should subsequently start implementing them, and carrying > out their own market tests. How many years would this represent? > > E. Only JFC Morfin seems to insist on the routing path to be > controlled by the sending end (upon receiving end data) and other > routing added value services to users. It seems that the list only > considers the network needs and not the user needs? He also seems the > only one to call for a DDDS approach of the routing computation? > > F. The US DoD has adopted IPv6 as per http://whitehouse.gov/pcipb. > Several Telecos, including BT in England, are committed to MLPS for > telephone services. China is expected to be rapidly a large user of > IPv6 (or to study its own IPv10 hoax(?)/project(?)). The ITU > development of NGN is supposed to be supported by IPv6. Moreover, the > GENI test bed as well. Can these deployments, experimentations, and > projects be affected by the problem that you are currently > investigating? In particular, could the US Defense Department meet > with congestion or technology follow-up problems? We therefore > understand that this topic is vital for the e-economy of the USA, > Europe, China, and India and will report it as such. > > I thank you for your time, attention, and help. > > Michel Gauthier. > mg@telepresse.com > ----- > All advice, leads, and clarifications are welcome. If you have any > information or private comments, please do not hesitate to send them > directly to Telepresse. Telepresse Intelligence Reports are > tailor-made and strictly confidential. Sources are never disclosed. > They are commissioned and intended for participating freelancers, > press agencies, corporate documentalists, and political analysts. > They are constantly updated. They may be written in French, Spanish, > English, or Japanese. Telepresse is a closed group of coopted > managers and journalists that practise mutual information and > documentation sharing. Telepresse does not offer external commercial > or private service. > ----- > > -------------------------------------------------------------------------------- > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Jan 08 14:16:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zyT-0004G1-Qe; Mon, 08 Jan 2007 14:16:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zyS-0004Fu-3H for architecture-discuss@ietf.org; Mon, 08 Jan 2007 14:16:00 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3zyQ-0002Cb-BR for architecture-discuss@ietf.org; Mon, 08 Jan 2007 14:16:00 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4E8B2212FAF; Mon, 8 Jan 2007 21:15:50 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 891CF212D6C; Mon, 8 Jan 2007 21:15:49 +0200 (EET) In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DC01178F72@tayexc14.americas.cpqcorp.net> <623826.82279.qm@web31802.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <800EB688-64B3-4139-9627-635769D4B685@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [arch-d] common synthesis Date: Mon, 8 Jan 2007 21:15:43 +0200 To: Michel Gauthier X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Michael, Unfortunately, I find your summary quite confused. I don't even know =20= where to start from when trying to read it. =46rom my very personal =20 point of view, you seem to use some key terms in a way that make it =20 pretty hard for me even to imagine what you really try to mean with =20 them. As an example, I have never heard that there would be any =20 established meaning for the tentative term IPv8; in fact, I have seen =20= various independent people used it in very different ways and to =20 denote very different architectural and even nonsensical concepts. --Pekka Nikander On 8 Jan 2007, at 01:41, Michel Gauthier wrote: > I prepare for Telepresse an intelligence report on the problem that =20= > has been identified by the IAB, and that is discussed by this =20 > mailing list, the solutions that it investigates for the Internet=92s =20= > future architecture, and its consequences. I would like to check =20 > with you about the main ideas that we extracted from this debate =20 > (we analysed the _key_ ideas for decision makers emerging from your =20= > active brainstorming). I also hope that my questions might help a =20 > common synthesis at this stage. > > 1. there is an over-complexity problem resulting from the size of =20 > the network. It is reflected in the size of the IPv6 address, the =20 > increasing use of multihoming, the BGP protocol instability, and =20 > the level of intelligence required from routers. Fred Baker =20 > provided some stunning examples making the problem still more =20 > difficult in real life. The IAB released a Draft on the issue. > > 2. there are three proposed attitudes: > > - a general attitude favouring band-aids for the 10 to 20 years to =20 > come, and a new architecture further on. Due to the urgency, it =20 > prefers delaying the analysis of the problem (as it takes too =20 > long), and prefers to start a rough consensus solution now. > > - JFC Morfin thinks that over-complexity is a stable new situation, =20= > and that it must be analysed and addressed with dedicated =20 > architectural concepts (distributed autonomy and subsidiarity) in =20 > turn completing RFC 1958 by Brian Carpenter, and RFC 3439 by Randy =20 > Bush and David Meyer. > > - Noel Chiappa, Pekka Nikander, Jim Bound, and John Day are looking =20= > at the longer term. John Day and JFC Morfin advocate a network =20 > operating system as cement for the possibly differing and time =20 > scaled solutions. > > 3. There are three possible options: one lead by Noel Chiappa/Pekka =20= > Nikander that is now at a near partial consensus, ad two other ones =20= > quoted by JFC Morfin. > > - IPv8: nobody wants it. It consists in keeping IPv4 addresses for =20 > NATs only, and adding NAT managed subaddressing. This solution =20 > would/will self deploy due to the expected increase of the price of =20= > IPv4 addresses. > > - IPv6: the IPv6 address space in IPv6 headers using IPv6 ITU /3 =20 > would be understood as a container for four orthogonal elements: =20 > header, routing, global identification, local extension. In =20 > addition routing management could be removed from the network and =20 > supervised at the edge as a multi-value added service extension of =20 > the DNS, basedon situation reports from en-route switchers. > > - Jack-up (?): it consists in adding a routing namespace with =20 > different possible solutions, which are not fully clarified yet. It =20= > is the most debated proposition. One of its main points is to =20 > address GNP issues. HIP and SHIM6 seem to be the experience behind =20 > that solution. Can it be qualified as an "MLPS6" approach? There is =20= > thus far no complete description of the proposed idea, but a Draft =20 > could be written soon by its promoters. > > All this raises some questions: > > A. what are the risks involved in the IPv8 solution developing - it =20= > seems that some organisations may already use variations of it? How =20= > to block it, or to make it acceptable if it is unavoidable? Could =20 > someone want to seriously document it and its cons/pros as a Draft? > > B. what is the difference between the IPv6 and Jack-up proposition? =20= > Jack-up is about two structural name spaces (IPv6 + a totally new =20 > one?). IPv6 is about immediate support of three orthogonal =20 > namespaces at the edges without real change, where only one =20 > structured one is currently supported? > > C. the "jack-up" approach seems too complex to introduce, unless a =20 > good transition strategy is adopted. What would that strategy be? =20 > Who would conduct it? Why would it be faster than the one used to =20 > promote IPv6 during the last 14 years? > > D. The time scale is: > - IPv8 is actually here already, but just not documented, > - IPv6 is here, but would need the ITU to document its use of an =20 > IPv6 /3 to support it. > No indication is given about a scenario for the jack-up =20 > proposition? It would require a WG to be created. It would produce =20 > different Drafts about the context, proposition, and transitioning. =20= > Then, industry should start developing applications, and test them. =20= > ISP and exchanges should subsequently start implementing them, and =20 > carrying out their own market tests. How many years would this =20 > represent? > > E. Only JFC Morfin seems to insist on the routing path to be =20 > controlled by the sending end (upon receiving end data) and other =20 > routing added value services to users. It seems that the list only =20 > considers the network needs and not the user needs? He also seems =20 > the only one to call for a DDDS approach of the routing computation? > > F. The US DoD has adopted IPv6 as per http://whitehouse.gov/pcipb . =20= > Several Telecos, including BT in England, are committed to MLPS for =20= > telephone services. China is expected to be rapidly a large user of =20= > IPv6 (or to study its own IPv10 hoax(?)/project(?)). The ITU =20 > development of NGN is supposed to be supported by IPv6. Moreover, =20 > the GENI test bed as well. Can these deployments, experimentations, =20= > and projects be affected by the problem that you are currently =20 > investigating? In particular, could the US Defense Department meet =20 > with congestion or technology follow-up problems? We therefore =20 > understand that this topic is vital for the e-economy of the USA, =20 > Europe, China, and India and will report it as such. > > I thank you for your time, attention, and help. > > Michel Gauthier. > mg@telepresse.com > ----- > All advice, leads, and clarifications are welcome. If you have any =20 > information or private comments, please do not hesitate to send =20 > them directly to Telepresse. Telepresse Intelligence Reports are =20 > tailor-made and strictly confidential. Sources are never disclosed. =20= > They are commissioned and intended for participating freelancers, =20 > press agencies, corporate documentalists, and political analysts. =20 > They are constantly updated. They may be written in French, =20 > Spanish, English, or Japanese. Telepresse is a closed group of =20 > coopted managers and journalists that practise mutual information =20 > and documentation sharing. Telepresse does not offer external =20 > commercial or private service. > ----- > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Jan 08 22:37:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47m0-0004nF-Aq; Mon, 08 Jan 2007 22:35:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47ly-0004lV-IE for architecture-discuss@ietf.org; Mon, 08 Jan 2007 22:35:38 -0500 Received: from montage.altserver.com ([72.34.52.22] helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H47lu-0005GO-DF for architecture-discuss@ietf.org; Mon, 08 Jan 2007 22:35:38 -0500 Received: from i03m-212-195-38-17.d4.club-internet.fr ([212.195.38.17] helo=asus) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1H47lp-0006JR-O3 for architecture-discuss@ietf.org; Mon, 08 Jan 2007 19:35:31 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Jan 2007 04:35:28 +0100 To: architecture-discuss@ietf.org From: JFCM Subject: [arch-d] common synthesis MIME-Version: 1.0 X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0911152309==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============0911152309== Content-Type: multipart/alternative; boundary="----MTufmknsuiaphbmfcrwihmxskcvgajxwlg" ------MTufmknsuiaphbmfcrwihmxskcvgajxwlg Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-22CA38DC Dear Michael, May be could you have sent me a mail/called me before involving me that much :-) ! >Actually, IPv8 would be IPv7. The reason there's no IPv5 is that >that was allocated to an experimental protocol. 7 is the next free number. >http://en.wikipedia.org/wiki/IPv5 As far as I understand from the indications obtained from people having lead the initial debate, IPv5 and IPv7 were two alternative approaches to the problem addressed by IPv6: IPv4 with a longer address size. You might ask Christian Huitema. Or the IRTF Chair. >Michel - Jim Fleming's IPv8 (which he'd been advocating since 1998 >or before) is vapourware (and nonsensical), As far as I understood Jim, he has two propositions - structural and operational: - to use available space in the IPv4 header to locate local address extension. I understand that several Linux projects did that too. - a complex administration system to best use that space. Jim kept documenting it. IMHO he made the same mistake as the IPv4/IPv6 current solutions: he wanted to regulate the address portion he added. >and JFC Morfin can be most kindly described as delusional, not >technically clued up, and disruptive - Please do not worry about this ad-hominem. Ad-homina are a common reaction of someone facing an opposition to something he takes (or is paid to take) for granted and has therefore no technical response to oppose, while he is genuinely shocked/worried so he does not want just to hit the delete key. My IETF experience shows that it takes one to three years for points which started ad-homina against me to be either sometimes adopted, or more usually to be seriously discussed and to be left aside (because the IETF rough consensus based engineering prevents it to engage in multilateral approaches - what is the essence of my lead user vision). Everything being on line you can check. >which is why he's had his posting privileges suspended from more >IETF mailing lists than I can keep track of. I have been so far suspended from the WG-LTRU mailing list, I was leaving, due to a PR-action initiated by the owner of the ietf-languages@alvestrand.no. The point of contention was that this list is/is not the one we described in RFC 4646, and therefore is/is not an IETF list (I have been eventually banned from that list several months after having left it). I also have been banned from the main ietf list for having advertised and invited members there to a meeting organised with the Chair of my national ISOC Chapter. So, actually I have been actually banned from one list, on wrong terms. >Your intelligence report is only as good as its sources. Correct. > I think you can do better in terms of "decision makers". I understand that the "decision makers" you allude to are people who are to decide of the option they are to invest some big money on? At Monday 08/01/2007 21:15 +0200, Pekka Nikander wrote: >Dear Michael, >Unfortunately, I find your summary quite confused. I don't even know >where to start from when trying to read it. From my very personal >point of view, you seem to use some key terms in a way that make it >pretty hard for me even to imagine what you really try to mean with >them. As an example, I have never heard that there would be any >established meaning for the tentative term IPv8; in fact, I have seen >various independent people used it in very different ways and to >denote very different architectural and even nonsensical concepts. I agree with Pekka here. You actually present three propositions: Jim Flemming's, mine, and the IETF one under debate, no bad :-) ! I suggest you keep discussing the IETF issue on this list. I will explain you my position directly (I also suggest you contact Members of the ITU/SG 17). I agree that the "IPv8" solution has unfortunately most probably a future. I am sure no one will help you here about it. As a myself a standardizer in other areas, I need to make sure that what we document can be supported under IPv4, IPv6, what you name MPLS6 and IPv8. So, the point interests me. I will try to see into it more precisely. I will then tell you off list what I may have found. Yet, please, fo not be in hurry. You may also want to contact Chinese people who discussed IPv10. It is usually considered as an hoax, but I think it was more a way to float some Chinese loc/id vision, may be in a way similar to what I propose for IPv6. >>On 8 Jan 2007, at 01:41, Michel Gauthier wrote: >>- JFC Morfin thinks that over-complexity is a stable new situation, >>and that it must be analysed and addressed with dedicated >>architectural concepts (distributed autonomy and subsidiarity) in >>turn completing RFC 1958 by Brian Carpenter, and RFC 3439 by Randy >>Bush and David Meyer. More or less, yes. But this goes with a normated model and more involved architectural considerations and experience. I will discuss that in a private mail. The IETF core values (RFC 3935) includes "decentralized control, edge-user empowerment and sharing of resources" that I do not share, at lease in the way the IETF currently understands them. The reason why they do not understand and oppose me. >>John Day and JFC Morfin advocate a network >>operating system as cement for the possibly differing and time >>scaled solutions. I consider that the IETF defines protocols, not a structured network environment, and lacks an interoperating system. >>- IPv8: nobody wants it. It consists in keeping IPv4 addresses for >>NATs only, and adding NAT managed subaddressing. This solution >>would/will self deploy due to the expected increase of the price of >>IPv4 addresses. I discussed that in several fora. This was both positive and negative. IMHA I think it is a possibility. I am not alone. >>- IPv6: the IPv6 address space in IPv6 headers using IPv6 ITU /3 >>would be understood as a container for four orthogonal elements: >>header, routing, global identification, local extension. In >>addition routing management could be removed from the network and >>supervised at the edge as a multi-value added service extension of >>the DNS, based on situation reports from en-route switchers. Kind of description of my position. However this is very "IETF" style because it simplifies a lot the nature of the address. I will send you some documents on this. >>- Jack-up (?): it consists in adding a routing namespace with >>different possible solutions, which are not fully clarified yet. It >>is the most debated proposition. One of its main points is to >>address GNP issues. HIP and SHIM6 seem to be the experience behind >>that solution. Can it be qualified as an "MLPS6" approach? There is >>thus far no complete description of the proposed idea, but a Draft >>could be written soon by its promoters. This is confuse. May be should you subscribe to the RAM mailing list and digest what is discussed there? >>All this raises some questions: >> >>A. what are the risks involved in the IPv8 solution developing - it >>seems that some organisations may already use variations of it? How >>to block it, or to make it acceptable if it is unavoidable? Could >>someone want to seriously document it and its cons/pros as a Draft? If this takes off, it will be a grassroots development; or may be a Chinese project as they have many NATs. As far as I understand the specs are pretty straight forward. >>B. what is the difference between the IPv6 and Jack-up proposition? >>Jack-up is about two structural name spaces (IPv6 + a totally new >>one?). IPv6 is about immediate support of three orthogonal >>namespaces at the edges without real change, where only one >>structured one is currently supported? No. IPv6 is the current IETF proposition. What you shorten here as "IPv6" is _my_ IPv6 proposition. >>D. The time scale is: >>- IPv8 is actually here already, but just not documented, >>- IPv6 is here, but would need the ITU to document its use of an >>IPv6 /3 to support it. As far as I understand you, this is correct. >>No indication is given about a scenario for the jack-up >>proposition? It would require a WG to be created. It would produce >>different Drafts about the context, proposition, and transitioning. >>Then, industry should start developing applications, and test them. >>ISP and exchanges should subsequently start implementing them, and >>carrying out their own market tests. How many years would this >>represent? I think this is more or less correct. But I suppose no one can give you a timing. However, if this is under some pressure it might go faster than usual. Yet, the decision is very important, so it may take time. This is why, as a lead user, I feel that the two first solutions are likely to happen because they could work now. >>E. Only JFC Morfin seems to insist on the routing path to be >>controlled by the sending end (upon receiving end data) and other >>routing added value services to users. It seems that the list only >>considers the network needs and not the user needs? He also seems >>the only one to call for a DDDS approach of the routing computation? No: I did not follow the RAM discussion, but some others proposed parts of such a type of approach. As a lead user I am more interested into this. Also, and I have actually seen it implemented on international public services nearly 30 years ago, so I know its importance. This is also a good way to support externets (not an IETF concept yet: external network lookalike within the network). >>F. The US DoD has adopted IPv6 as per http://whitehouse.gov/pcipb . >>Several Telecos, including BT in England, are committed to MPLS for >>telephone services. China is expected to be rapidly a large user of >>IPv6 (or to study its own IPv10 hoax(?)/project(?)). The ITU >>development of NGN is supposed to be supported by IPv6. Moreover, >>the GENI test bed as well. Can these deployments, experimentations, >>and projects be affected by the problem that you are currently >>investigating? In particular, could the US Defense Department meet >>with congestion or technology follow-up problems? We therefore >>understand that this topic is vital for the e-economy of the USA, >>Europe, China, and India and will report it as such. You call for pure divination here! I understand that you want to tell people where to put their money and developers. As a lead-user I meet some of the questions you raise (in a different way since I am not the Pentagon). My problem is the connectivity and the interoperability of _my_ home corebox (and of my fellow users). IMHO this is far too early to discuss this. Even if for many this is a reasonable question. Good luck. jfc ------MTufmknsuiaphbmfcrwihmxskcvgajxwlg Content-Type: text/html Dear Michael,
May be could you have sent me a mail/called me before involving me
that much :-) !

>Actually, IPv8 would be IPv7. The reason there's no IPv5 is that
>that was allocated to an experimental protocol. 7 is the next free number.
>http://en.wikipedia.org/wiki/IPv5

As far as I understand from the indications obtained from people
having lead the initial debate, IPv5 and IPv7 were two alternative
approaches to the problem addressed by IPv6: IPv4 with a longer
address size. You might ask Christian Huitema. Or the IRTF Chair.

>Michel - Jim Fleming's IPv8 (which he'd been advocating since 1998
>or before) is vapourware (and nonsensical),

As far as I understood Jim, he has two propositions - structural and
operational:
- to use available space in the IPv4 header to locate local address
extension. I understand that several Linux projects did that too.
- a complex administration system to best use that space. Jim kept
documenting it. IMHO he made the same mistake as the IPv4/IPv6
current solutions: he wanted to regulate the address portion he added.

>and JFC Morfin can be most kindly described as delusional, not
>technically clued up, and disruptive -

Please do not worry about this ad-hominem. Ad-homina are a common
reaction of someone facing an opposition to something he takes (or is
paid to take) for granted and has therefore no technical response to
oppose, while he is genuinely shocked/worried so he does not want
just to hit the delete key.

My IETF experience shows that it takes one to three years for points
which started ad-homina against me to be either sometimes adopted, or
more usually to be seriously discussed and to be left aside (because
the IETF rough consensus based engineering prevents it to engage in
multilateral approaches - what is the essence of my lead user
vision). Everything being on line you can check.

>which is why he's had his posting privileges suspended from more
>IETF mailing lists than I can keep track of.

I have been so far suspended from the WG-LTRU mailing list, I was
leaving, due to a PR-action initiated by the owner of the
ietf-languages@alvestrand.no. The point of contention was that this
list is/is not the one we described in RFC 4646, and therefore is/is
not an IETF list (I have been eventually banned from that list
several months after having left it). I also have been banned from
the main ietf list for having advertised and invited members there to
a meeting organised with the Chair of my national ISOC Chapter. So,
actually I have been actually banned from one list, on wrong terms.

>Your intelligence report is only as good as its sources.

Correct.

>  I think you can do better in terms of "decision makers".

I understand that the "decision makers" you allude to are people who
are to decide of the option they are to invest some big money on?

At Monday 08/01/2007 21:15 +0200, Pekka Nikander wrote:
>Dear Michael,
>Unfortunately, I find your summary quite confused.  I don't even know
>where to start from when trying to read it.  From my very personal
>point of view, you seem to use some key terms in a way that make it
>pretty hard for me even to imagine what you really try to mean with
>them.  As an example, I have never heard that there would be any
>established meaning for the tentative term IPv8; in fact, I have seen
>various independent people used it in very different ways and to
>denote very different architectural and even nonsensical concepts.

I agree with Pekka here.

You actually present three propositions: Jim Flemming's, mine, and
the IETF one under debate, no bad :-) ! I suggest you keep discussing
the IETF issue on this list. I will explain you my position directly
(I also suggest you contact Members of the ITU/SG 17).

I agree that the "IPv8" solution has unfortunately most probably a
future. I am sure no one will help you here about it. As a myself a
standardizer in other areas, I need to make sure that what we
document can be supported under IPv4, IPv6, what you name MPLS6 and
IPv8. So, the point interests me. I will try to see into it more
precisely. I will then tell you off list what I may have found. Yet,
please, fo not be in hurry.

You may also want to contact Chinese people who discussed IPv10. It
is usually considered as an hoax, but I think it was more a way to
float some Chinese loc/id vision, may be in a way similar to what I
propose for IPv6.

>>On 8 Jan 2007, at 01:41, Michel Gauthier wrote:
>>- JFC Morfin thinks that over-complexity is a stable new situation,
>>and that it must be analysed and addressed with dedicated
>>architectural concepts (distributed autonomy and subsidiarity) in
>>turn completing RFC 1958 by Brian Carpenter, and RFC 3439 by Randy
>>Bush and David Meyer.

More or less, yes. But this goes with a normated model and
more
involved architectural considerations and experience. I will discuss
that in a private mail. The IETF core values (RFC 3935) includes
"decentralized control, edge-user empowerment and sharing of
resources" that I do not share, at lease in the way the IETF
currently understands them. The reason why they do not understand and
oppose me.

>>John Day and JFC Morfin advocate a network
>>operating system as cement for the possibly differing and time
>>scaled solutions.

I consider that the IETF defines protocols, not a structured network
environment, and lacks an interoperating system.

>>- IPv8: nobody wants it. It consists in keeping IPv4 addresses for
>>NATs only, and adding NAT managed subaddressing. This solution
>>would/will self deploy due to the expected increase of the price of
>>IPv4 addresses.

I discussed that in several fora. This was both positive and
negative. IMHA I think it is a possibility. I am not alone.

>>- IPv6: the IPv6 address space in IPv6 headers using IPv6 ITU /3
>>would be understood as a container for four orthogonal elements:
>>header, routing, global identification, local extension. In
>>addition routing management could be removed from the network and
>>supervised at the edge as a multi-value added service extension of
>>the DNS, based on situation reports from en-route switchers.

Kind of description of my position. However this is very "IETF" style
because it simplifies a lot the nature of the address. I will send
you some documents on this.

>>- Jack-up (?): it consists in adding a routing namespace with
>>different possible solutions, which are not fully clarified yet. It
>>is the most debated proposition. One of its main points is to
>>address GNP issues. HIP and SHIM6 seem to be the experience behind
>>that solution. Can it be qualified as an "MLPS6" approach? There is
>>thus far no complete description of the proposed idea, but a Draft
>>could be written soon by its promoters.

This is confuse. May be should you subscribe to the RAM mailing list
and digest what is discussed there?

>>All this raises some questions:
>>
>>A. what are the risks involved in the IPv8 solution developing - it
>>seems that some organisations may already use variations of it? How
>>to block it, or to make it acceptable if it is unavoidable? Could
>>someone want to seriously document it and its cons/pros as a Draft?

If this takes off, it will be a grassroots development; or may be a
Chinese project as they have many NATs. As far as I understand the
specs are pretty straight forward.

>>B. what is the difference between the IPv6 and Jack-up proposition?
>>Jack-up is about two structural name spaces (IPv6 + a totally new
>>one?). IPv6 is about immediate support of three orthogonal
>>namespaces at the edges without real change, where only one
>>structured one is currently supported?

No. IPv6 is the current IETF proposition.
What you shorten here as "IPv6" is _my_ IPv6 proposition.

>>D. The time scale is:
>>- IPv8 is actually here already, but just not documented,
>>- IPv6 is here, but would need the ITU to document its use of an
>>IPv6 /3 to support it.

As far as I understand you, this is correct.

>>No indication is given about a scenario for the jack-up
>>proposition? It would require a WG to be created. It would produce
>>different Drafts about the context, proposition, and transitioning.
>>Then, industry should start developing applications, and test them.
>>ISP and exchanges should subsequently start implementing them, and
>>carrying out their own market tests. How many years would this
>>represent?

I think this is more or less correct. But I suppose no one can give
you a timing. However, if this is under some pressure it might go
faster than usual. Yet, the decision is very important, so it may
take time. This is why, as a lead user, I feel that the two first
solutions are likely to happen because they could work now.

>>E. Only JFC Morfin seems to insist on the routing path to be
>>controlled by the sending end (upon receiving end data) and other
>>routing added value services to users. It seems that the list only
>>considers the network needs and not the user needs? He also seems
>>the only one to call for a DDDS approach of the routing computation?

No: I did not follow the RAM discussion, but some others proposed
parts of such a type of approach. As a lead user I am more interested
into this. Also, and I have actually seen it implemented on
international public services nearly 30 years ago, so I know its
importance. This is also a good way to support externets (not an IETF
concept yet: external network lookalike within the network).

>>F. The US DoD has adopted IPv6 as per http://whitehouse.gov/pcipb .
>>Several Telecos, including BT in England, are committed to MPLS for
>>telephone services. China is expected to be rapidly a large user of
>>IPv6 (or to study its own IPv10 hoax(?)/project(?)). The ITU
>>development of NGN is supposed to be supported by IPv6. Moreover,
>>the GENI test bed as well. Can these deployments, experimentations,
>>and projects be affected by the problem that you are currently
>>investigating? In particular, could the US Defense Department meet
>>with congestion or technology follow-up problems? We therefore
>>understand that this topic is vital for the e-economy of the USA,
>>Europe, China, and India and will report it as such.

You call for pure divination here!

I understand that you want to tell people where to put their money
and developers. As a lead-user I meet some of the questions you raise
(in a different way since I am not the Pentagon). My problem is the
connectivity and the interoperability of _my_ home corebox (and of my
fellow users). IMHO this is far too early to discuss this. Even if
for many this is a reasonable question.

Good luck.
jfc

------MTufmknsuiaphbmfcrwihmxskcvgajxwlg-- --===============0911152309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0911152309==-- From architecture-discuss-bounces@ietf.org Wed Jan 10 08:57:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dvi-0006Sz-2C; Wed, 10 Jan 2007 08:55:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dvf-0006So-VC for architecture-discuss@ietf.org; Wed, 10 Jan 2007 08:55:47 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4dve-0003WY-N3 for architecture-discuss@ietf.org; Wed, 10 Jan 2007 08:55:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id D92B226C1FC; Wed, 10 Jan 2007 14:55:34 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4D91626C15C; Wed, 10 Jan 2007 14:55:34 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 3F71558ED14; Wed, 10 Jan 2007 14:55:34 +0100 (CET) Date: Wed, 10 Jan 2007 14:55:34 +0100 From: Stephane Bortzmeyer To: Michel Gauthier Subject: Re: [arch-d] common synthesis Message-ID: <20070110135534.GA2960@nic.fr> References: <816DD9299957E547B5D758D7F977D6DC01178F72@tayexc14.americas.cpqcorp.net> <623826.82279.qm@web31802.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, Jan 08, 2007 at 12:41:42AM +0100, Michel Gauthier wrote a message of 261 lines which said: > I prepare for Telepresse an intelligence report As it is today, it could do a lot of damage to your own credibility and I suggest to do more research before publishing that. Mentioning JFC Morfin (apart for a bit of relaxation and humour) and the non-existent IPv8 is a seriously wrong start. > - IPv8 is actually here already, but just not documented, Thank you for the ROTFL of the day :-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Jan 12 12:05:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PpH-0004WE-BZ; Fri, 12 Jan 2007 12:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PpF-0004Vy-Q6 for architecture-discuss@ietf.org; Fri, 12 Jan 2007 12:04:21 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5PpF-0002iX-Az for architecture-discuss@ietf.org; Fri, 12 Jan 2007 12:04:21 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0CH4keM047489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Jan 2007 18:04:47 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Iljitsch van Beijnum Date: Fri, 12 Jan 2007 18:04:16 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [arch-d] 1. the architecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org [It seems the discussions directly related to the IAB workshop have moved elsewhere, can someone give me a pointer?] If we're going to talk architecture, we should discuss the architecture of what the network will do for its users, and the generalities of how it will accomplish those things. Naming issues are largely irrelevant to such a discussion. At the highest level, the network is about allowing people, and the devices working on their behalf, to communicate. In that sense, it's perfectly reasonable to hold up something with a corporate logo up before a built-in camera and ask the computer or communication device to set up a connection towards the corporation the logo belongs to. Since putting images in the IP destination field doesn't produce the intended result, this obviously involves a number of disambiguation and capabilitity discovery/negotation steps that fortunately, we don't have to worry about in our little architectural corner. But at some point these activities should result in something that looks like a URL. Today's URLs are pretty bad. The FQDN part is the best part, this even works so well that we haven't even bothered to improve our DNS technology significantly the past two decades. So any problems here are due to operational issues rather than fundamental ones, in my opinion. But the bad part is that we put the application part before the FQDN part in the URL, and a low-level detail in the form of the port number is implicitly or explicitly part of the URL. A better architecture would be to specify a destination and one or more applications or communication methods that we are prepared to use, and then let lower layers take care of the rest. Each lower layer has to live with certain restrictions and brings certain additional information to the table. The same may be true for intermediate hops. So what should happen, is that the each layer or hop adds its own information, either in the forward direction toward the next layer or hop, or back to the previous one. At some point, the setup process reaches the destination, and if there is a sufficient set of common capabilities, the actual communication can start. Should at any point the communication stall (which we can detect using something similar to the REAP protocol that's part of the shim6 effort) we simply restart the negotiation process and uncork the communication after any required changes in the communication parameters. More concrete: when I want to talk to www.google.com, my system consults a distributed database to find initial points of contact for this destination. In this particular case, that won't be an actual WWW server, but rather a list of dispatch/load balancing devices. When (for instance) I end up talking to such a device in Chicago, that one may notice that I'm better served by talking to an actual server in Amsterdam, so it gives me the address for the least busy server there. I may have to talk to another intermediate device in Amsterdam, or maybe I'm immediately connected to a WWW server. Since this is a WWW server, it tells my system to invoke the default WWW brower, or maybe, the Google WWW browser if available. If I only have a generic browser, my system says so so the Google server knows to omit any Google-specific extensions. However, should I have be more paranoid, my initial packets to the Google point of contact could be intercepted by a local firewall which checks whether I am allowed to talk to the outside world and monitors the progress of the negotiation. When it notices that I want to use Intranet Exploder 1.0 as a WWW browser, the firewall consults its permission list and notices that there is a vulnerability for this version of that browser so it removes Intranet Exploder 1.0 from the list of applications (and sends an error message back to me for good measure). So either another application is selected for this session, or the session setup doesn't complete because there are no shared capabilities. Notice that this isn't 1.609 million kilometers removed from today's practice, except that today, most information is lost between layers and hops so a lot of guessing goes on, often successful but also often annoyingly unsuccessful, and leaving us preciously little room to improve the current internet. If designed properly, a network like this could handle all kinds of stuff that are very difficult today with great ease. For instance, the use of NAT becomes a non-issue as all the address rewriting now happens explicitly at known points. Interoperation between different network layer protocols is trivial for the same reason. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Jan 12 12:43:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QRC-0006gG-0y; Fri, 12 Jan 2007 12:43:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QRA-0006fD-QZ for architecture-discuss@ietf.org; Fri, 12 Jan 2007 12:43:32 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5QR7-0005jI-Am for architecture-discuss@ietf.org; Fri, 12 Jan 2007 12:43:32 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0CHhuL7048043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Jan 2007 18:43:57 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Iljitsch van Beijnum Date: Fri, 12 Jan 2007 18:43:26 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [arch-d] 2. thinking about an implementation X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Since none of us have the power to transform the internet over night, simply implementing the architecture that I outlined in my previous message, or any architecture that isn't 98% an enumeration of the current state of the network, isn't possible. So it's necessary to take that current state into consideration, and, more importantly, come up with solutions for today's problems, which I'll take to be the problems identified by the IAB routing and addressing workshop. The problem that we have is that the core routers need to forward packets very fast and they need to consider a lot of state doing it. This makes future growth very expensive. Either reducing the number of packets / forwarding speed or reducing the amount of state will keep the internet affordable. Alternatively, letting the people that benefit from the combined speed/state explosion pay makes the issue an economic one that will be solved through garden variety capitalism. We already have a reasonable model for paying for bandwidth, so we would have to come up with a model for paying for state, which is mostly multihoming, using provider independent address space and bad aggregation. Nobody has been able to suggest such a model that fits with the current structure of the network. So we're back on the technical side. Implied in the "jack up" term is the notion that there needs to be a completely new level. This is a problem. Introducing something new throughout the entire internet is pretty much a non-starter even in the long term. What we need is something that can be applied to the parts of the network where the pain is felt. This is in the large networks that use the fastest routers. Interestingly, for the most part, the large networks that have fast routers don't have or need fast routers everywhere: there is generally an aggregation / customer facing group of routers that is much more modest, and which don't need to keep the full BGP default-free state. The problems start when all the traffic going to all possible destinations in the world comes together. This is where both the speed and the state is required. There are several ways to avoid this speed/state combination: 1. Parallelization: have several fast routers that each have part of the state. So the "slow" routers send traffic for 0.0.0.0/2 to core router A, 64.0.0.0/2 to B, 128.0.0.0/2 to C and 192.0.0.0/2 to D. Core routers A - D only need a quarter of the full BGP table each. 2. Tunneling: have the "slow" routers encapsulate the traffic (not in IP, please, ethernet or MPLS is much more efficient!) and send it directly to the border of the network rather than have core routers look at it. 3. Internal aggregation: have a border router that handles 0.0.0.0/2, one that handles 64.0.0.0/2 and so on. This works much better if address allocation is non-random (see http://www.muada.com/drafts/ draft-van-beijnum-multi6-isp-int-aggr-01.txt ) but it works with current addressing as well if the resulting stretch is considered acceptable. (Observe that moving packets as per an aggregate or as per a tunnel address accomplishes the exact same thing.) 4. 90/10 rule: determine the 10% destination prefixes that suck up the most traffic (could be 90%) and put those in the fast routers, keep the other 90% of the prefixes that are the destination for the remaining 10% of the traffic in much slower routers that can use much cheaper technology. The jack up/down here is dynamic: remove a prefix form a fast router and packets toward it are automatically handled by the slow routers. Note that all of these are internal to an autonomous system and therefore deployable. More gains can be had by having ASes cooperate by having the source AS encapsulate and have the destination AS decapsulate. For this, we need new routing/signaling which we can optimize specifically for this task so it should be able to handle considerably more prefixes without trouble than what we can currently do today with BGP. And since the inter-AS encapsulation is an additional optimization rather than a required first step, this too should be reasonably deployable. The third step is allowing end-users to participate in the encapsulation/decapsulation which should allow adding additional features such as mobility and end-user TE/optimization. And suddenly we're close to the "negotiate information at every step" model, too. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Jan 12 15:53:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5TOE-000579-EE; Fri, 12 Jan 2007 15:52:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5TOB-00052y-Ml for architecture-discuss@ietf.org; Fri, 12 Jan 2007 15:52:39 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5TO5-0005OM-BK for architecture-discuss@ietf.org; Fri, 12 Jan 2007 15:52:39 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 8F5625641B; Fri, 12 Jan 2007 15:52:31 -0500 (EST) Date: Fri, 12 Jan 2007 15:52:31 -0500 From: John Leslie To: Iljitsch van Beijnum Subject: Re: [arch-d] 1. the architecture Message-ID: <20070112205231.GB60501@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Iljitsch van Beijnum wrote: > > [It seems the discussions directly related to the IAB workshop have > moved elsewhere, can someone give me a pointer?] (There's more discussion on right now...) > If we're going to talk architecture, we should discuss the > architecture of what the network will do for its users, and the > generalities of how it will accomplish those things. Naming issues > are largely irrelevant to such a discussion. There are strong opinions about naming: I wouldn't call naming "irrelevant"; but it certainly can be "distracting". > At the highest level, the network is about allowing people, and the > devices working on their behalf, to communicate. In that sense, it's > perfectly reasonable to hold up something with a corporate logo up > before a built-in camera and ask the computer or communication device > to set up a connection towards the corporation the logo belongs to. Agreed, but it's not our job to make that work... > Since putting images in the IP destination field doesn't produce the > intended result, this obviously involves a number of disambiguation > and capabilitity discovery/negotation steps that fortunately, we > don't have to worry about in our little architectural corner. (If that isn't true, I'd argue we've chosen the wrong corner.) > But at some point these activities should result in something that > looks like a URL. Today's URLs are pretty bad. The FQDN part is the > best part, this even works so well that we haven't even bothered to > improve our DNS technology significantly the past two decades. So any > problems here are due to operational issues rather than fundamental > ones, in my opinion. But the bad part is that we put the application > part before the FQDN part in the URL, and a low-level detail in the > form of the port number is implicitly or explicitly part of the URL. This feels like the wrong corner to me... > > More concrete: when I want to talk to www.google.com, my system > consults a distributed database to find initial points of contact for > this destination. ... which is exactly what happens today. What looks like a single to the user can involve dozens of different TCP connections... > > However, should I have be more paranoid, my initial packets to the > Google point of contact could be intercepted by a local firewall > which checks whether I am allowed to talk to the outside world and > monitors the progress of the negotiation. Now we're getting near "architecture". Employers _do_ want to control that sort of thing, and our current architecture doesn't help them... > OTOH, most of what they want can be approximated by running all employee traffic through proxy servers. The fact that folks look to buy "firewalls" to do this is _not_ (IMHO) an architectural problem. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Jan 12 16:23:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Trs-0000U4-A8; Fri, 12 Jan 2007 16:23:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Trq-0000Tz-Cy for architecture-discuss@ietf.org; Fri, 12 Jan 2007 16:23:18 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Trn-0004lr-FN for architecture-discuss@ietf.org; Fri, 12 Jan 2007 16:23:18 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id E421656417; Fri, 12 Jan 2007 16:23:11 -0500 (EST) Date: Fri, 12 Jan 2007 16:23:09 -0500 From: John Leslie To: Iljitsch van Beijnum Subject: Re: [arch-d] 2. thinking about an implementation Message-ID: <20070112212309.GC60501@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Iljitsch van Beijnum wrote: > > The problem that we have is that the core routers need to forward > packets very fast and they need to consider a lot of state doing it. I agree 100%. > This makes future growth very expensive. Either reducing the number > of packets / forwarding speed or reducing the amount of state will > keep the internet affordable. Well said! > Alternatively, letting the people that benefit from the combined > speed/state explosion pay makes the issue an economic one that will > be solved through garden variety capitalism. Alas, it's hard to agree who should be asked to pay... > We already have a reasonable model for paying for bandwidth, so we > would have to come up with a model for paying for state, Good point. > which is mostly multihoming, using provider independent address space > and bad aggregation. Well, No... "State" is stuff which changes. Especially, "state" is stuff which changes fast enough that synchronizing it is non-trivial. > Nobody has been able to suggest such a model that fits with the > current structure of the network. So we're back on the technical > side. No. We're into an area where architecture can really help. > Implied in the "jack up" term is the notion that there needs to be a > completely new level. This is a problem. Introducing something new > throughout the entire internet is pretty much a non-starter even in > the long term. Actually, the problem with "jack-up" is that it _increases_ the "state" information we're likely to need to synchronize. What's a non-starter is designing around a "flag day". > What we need is something that can be applied to the parts of the > network where the pain is felt. This is in the large networks that > use the fastest routers. That's by no means the only place the pain is felt... > Interestingly, for the most part, the large networks that have fast > routers don't have or need fast routers everywhere: there is generally > an aggregation / customer facing group of routers that is much more > modest, and which don't need to keep the full BGP default-free state. That seems obvious to us. Alas, it's not as obvious to the management of the companies operating those routers. Furthermore, BGP thrashing inflicts pain much more widely than that paradigm would suggest... > The problems start when all the traffic going to all possible > destinations in the world comes together. (Which, of course, need not happen in the first place -- as you later observe...) > This is where both the speed and the state is required. This is where speed is required. "State" could actually be relaxed a bit here, if we could escape telco-think and agree that state changes _will_ interrupt forwarding... > There are several ways to avoid this speed/state combination: > > 1. Parallelization... > 2. Tunneling... > 3. Internal aggregation... > 4. 90/10 rule... These and other tricks can be made to handle the speed issue -- which is why I have said that mere size of the forwarding table isn't enough to justify this effort. It's synchronizing the "state" that can't scale. > Note that all of these are internal to an autonomous system and > therefore deployable. More gains can be had by having ASes cooperate > by having the source AS encapsulate and have the destination AS > decapsulate. For this, we need new routing/signaling which we can > optimize specifically for this task so it should be able to handle > considerably more prefixes without trouble than what we can currently > do today with BGP. And since the inter-AS encapsulation is an > additional optimization rather than a required first step, this too > should be reasonably deployable. Indeed. (Though this requires _some_ architectural work first...) > The third step is allowing end-users to participate in the > encapsulation/decapsulation which should allow adding additional > features such as mobility and end-user TE/optimization. This is where I lose you. I do believe there are things we could handle end-to-end, but encapsulation & aggregation aren't among them. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Jan 12 17:53:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5VGi-0007W8-KG; Fri, 12 Jan 2007 17:53:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5VGh-0007Vy-GB for architecture-discuss@ietf.org; Fri, 12 Jan 2007 17:53:03 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5VGh-00007z-4y for architecture-discuss@ietf.org; Fri, 12 Jan 2007 17:53:03 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0CMrSYS052201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jan 2007 23:53:28 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20070112205231.GB60501@verdi> References: <20070112205231.GB60501@verdi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D5492AF-A126-42E0-92AA-F26821D5D97A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] 1. the architecture Date: Fri, 12 Jan 2007 23:52:49 +0100 To: John Leslie X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 12-jan-2007, at 21:52, John Leslie wrote: >> If we're going to talk architecture, we should discuss the >> architecture of what the network will do for its users, and the >> generalities of how it will accomplish those things. Naming issues >> are largely irrelevant to such a discussion. > There are strong opinions about naming: I wouldn't call naming > "irrelevant"; but it certainly can be "distracting". My strong opinion is that it is largely irrelevant. There are two aspects to a name: its relationship to the object that it names, and its structure. It's tempting to attach meaning to names, but that's an exercise in futility, because whenever the circumstances change, so must the names. Successful names are ones that have no inherent meaning and can be used for many purposes. As such they're as interesting as a blank sheet of paper: lots of potential, but nothing else. The corollary is that for any long-lived naming system, that type of name will be used for all purposes it can possibly be used for. The hierarchical structure of names may seem important at first glance, but once the names have been assigned, looking them up can be done with only slight differences in effort in several scalable ways. IP prefixes are assigned pretty much randomly, but we have very fast FIB lookup algorithms nonetheless. DNS names make for a nice hierarchy but finding arbitrary hash values in a distributed system also works with dynamic hash tables. Replication and other database techniques can make (distributed) lookups fast on pretty much anything. (The trouble is with distributed updates.) Ok, maybe I'm being a bit too harsh here. You can encode one value into a name or address "for free". With CIDR that's a pointer to the ISP, but other choices are also possible. But CIDR isn't relevant to PI addressing, hence our troubles. >> >> More concrete: when I want to talk to www.google.com, my system >> consults a distributed database to find initial points of contact for >> this destination. > ... which is exactly what happens today. What looks like a single > to the user can involve dozens of different TCP connections... The difference is that today, one end knows what's really going on, but it tricks the other end into thinking that we're dealing with 1980s pre-CIDR, pre-DNS IP (which wasn't a bad architecture, just a limited one). >> However, should I have be more paranoid, my initial packets to the >> Google point of contact could be intercepted by a local firewall >> which checks whether I am allowed to talk to the outside world and >> monitors the progress of the negotiation. > Now we're getting near "architecture". Employers _do_ want to > control that sort of thing, and our current architecture doesn't help > them... What I'd like to see is all of this being explicit at the (meta-) session setup, rather than have firewall meddling show up as seemingly random breakage. Doing a recursive setup also allows both the transparent end-to-end model (talk directly to the destination and be done) as the degenerative case where we need to negotiate with / be NATed by each hop along the way, and, more importantly, survive any bad side effects from the latter. When we know that the school firewall doesn't allow us to talk to myspace.com we then have the option to engage the 3G radio and see if the cell provider is more liberal, if we care enough. > OTOH, most of what they want can be approximated by running all > employee traffic through proxy servers. The fact that folks look to > buy "firewalls" to do this is _not_ (IMHO) an architectural problem. Proxies is exactly what I had in mind. Because HTTP proxies see the real identifier and not just the one implied by the destination address, they can do much more than a NAT box. But I only want this at setup. Once that's done, packets should flow with minimal processing by intermediate devices. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Jan 12 18:19:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5VfP-00084a-IU; Fri, 12 Jan 2007 18:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5VfO-00084V-Ec for architecture-discuss@ietf.org; Fri, 12 Jan 2007 18:18:34 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5VfO-0005LA-0I for architecture-discuss@ietf.org; Fri, 12 Jan 2007 18:18:34 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0CNJ1v1052557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 13 Jan 2007 00:19:02 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20070112212309.GC60501@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] 2. thinking about an implementation Date: Sat, 13 Jan 2007 00:18:31 +0100 To: John Leslie X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 12-jan-2007, at 22:23, John Leslie wrote: >> Alternatively, letting the people that benefit from the combined >> speed/state explosion pay makes the issue an economic one that will >> be solved through garden variety capitalism. > Alas, it's hard to agree who should be asked to pay... Actually the really hard part would be to determine who gets the money... This only works when the actual extra work that comes from using PI or multihoming must be done by the PI user / multihomer, I don't think pricing is a usable mechanism here. But of course I'm not an economist, nor do I play one on TV. >> which is mostly multihoming, using provider independent address space >> and bad aggregation. > Well, No... "State" is stuff which changes. Especially, "state" is > stuff which changes fast enough that synchronizing it is non-trivial. There are two parts: the synchronizing and then the lookups at packet forwarding time. Both have the potential to be problematic, although I think the former is more easily parallelizeable and better protocols will also help a lot. With the BGP hammer every possible type of event looks like a routing update nail and the nails have the ugly tendency to multiply to boot. >> Implied in the "jack up" term is the notion that there needs to be a >> completely new level. This is a problem. Introducing something new >> throughout the entire internet is pretty much a non-starter even in >> the long term. > Actually, the problem with "jack-up" is that it _increases_ the > "state" information we're likely to need to synchronize. Volume in itself isn't all that relevant. 100 spam emails a day is an annoyance, 100 spam phone calls a day is a full time job. Disseminating a lot of state information in and of itself isn't immediately fatal if we can avoid having to update it very often or having to do lookups on it very fast. I.e., if an edge box that lives at 1 Gbps or lower bandwidth only has to encapsulate packets without considering reachability because rerouting at the outer header protocol takes care of that, it could work well. > What's a non-starter is designing around a "flag day". It's even worse. Going from IPv4 to IPv6 with a flag day won't work. But going from IPv4 to dual stack and then from dual stack to IPv6 doesn't work either, even though no flag day is required, because in a network the size of the internet it's impossible to complete any action that involves changes to every { host | stack | router | AS | ... } . There will always be holdouts. >> The third step is allowing end-users to participate in the >> encapsulation/decapsulation which should allow adding additional >> features such as mobility and end-user TE/optimization. > This is where I lose you. I do believe there are things we could > handle end-to-end, but encapsulation & aggregation aren't among them. The first step is to have edge (customer-facing) routers in ISP networks encapsulate and border routers decapsulate in order to make packets flow through the core without the core needing to have the 90% prefixes that generate 10% of the traffic. The second step is to encapsulate at the source edge and decapsulate at the destination edge, so the border routers don't have to see the "vanity prefixes" either. The third step is to optionally have customers encapsulate and/or decapsulate. This saves capacity on the ISP edge routers and allows the customer equipment to make smarter decisions. Compare this to the likes of shim6 where the hosts perform the encapsulation/decapsulation so the whole thing is transparent to ALL routers. The big advantage of doing all of this in ISP networks is that that way, customers don't get to see their locator addresses so they aren't tempted to hardcode those all over the place. With something like shim6 you still have the renumbering problem which creates the need for PI which creates the routing state explosion. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Jan 13 17:56:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5rlb-00032T-U9; Sat, 13 Jan 2007 17:54:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5rla-00032N-AP for architecture-discuss@ietf.org; Sat, 13 Jan 2007 17:54:26 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5rlZ-00077p-1Q for architecture-discuss@ietf.org; Sat, 13 Jan 2007 17:54:26 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 7833E5641C; Sat, 13 Jan 2007 17:54:13 -0500 (EST) Date: Sat, 13 Jan 2007 17:54:11 -0500 From: John Leslie To: Iljitsch van Beijnum Subject: Re: [arch-d] 2. thinking about an implementation Message-ID: <20070113225411.GD60501@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Iljitsch van Beijnum wrote: > On 12-jan-2007, at 22:23, John Leslie wrote: > >> ... "State" is stuff which changes. Especially, "state" is stuff >> which changes fast enough that synchronizing it is non-trivial. > > There are two parts: the synchronizing and then the lookups at packet > forwarding time. If the lookup isn't local, we (probably) haven't synchronized. > Both have the potential to be problematic, although I think the former > is more easily parallelizeable and better protocols will also help a > lot. Perfect synchronization isn't possible throughout the routing fabric. > With the BGP hammer every possible type of event looks like a routing > update nail and the nails have the ugly tendency to multiply to boot. Well, yes, we could do better than BGP... But architecture is about avoiding any need to use BGP-like tools where they can't work well. >> Actually, the problem with "jack-up" is that it _increases_ the >> "state" information we're likely to need to synchronize. > > ... Disseminating a lot of state information in and of itself isn't > immediately fatal if we can avoid having to update it very often or > having to do lookups on it very fast. I.e., if an edge box that lives > at 1 Gbps or lower bandwidth only has to encapsulate packets without > considering reachability because rerouting at the outer header > protocol takes care of that, it could work well. Indeed, edge routers could afford to synchronize more state than backbone routers can. >> What's a non-starter is designing around a "flag day". > > It's even worse. Going from IPv4 to IPv6 with a flag day won't work. > But going from IPv4 to dual stack and then from dual stack to IPv6 > doesn't work either, even though no flag day is required, because in > a network the size of the internet it's impossible to complete any > action that involves changes to every { host | stack | router | AS > | ... } . There will always be holdouts. Going from IPv4 to dual-stack _does_ work. (I agree IPv4 won't disappear anytime soon.) >>> The third step is allowing end-users to participate in the >>> encapsulation/decapsulation which should allow adding additional >>> features such as mobility and end-user TE/optimization. > >> This is where I lose you. I do believe there are things we could >> handle end-to-end, but encapsulation & aggregation aren't among them. > > The first step is to have edge (customer-facing) routers in ISP > networks encapsulate and border routers decapsulate in order to make > packets flow through the core without the core needing to have the > 90% prefixes that generate 10% of the traffic. This is a rather big step; and it doesn't feel necessary... > The second step is to encapsulate at the source edge and decapsulate > at the destination edge, so the border routers don't have to see the > "vanity prefixes" either. What do you mean by "edge"? (This could be a critical architectural question.) > The third step is to optionally have customers encapsulate and/or > decapsulate. This saves capacity on the ISP edge routers and allows > the customer equipment to make smarter decisions. Designing the architecture for this looks like an interesting problem. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Jan 16 19:40:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ypQ-0005P7-BL; Tue, 16 Jan 2007 19:39:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ypP-0005P2-9h for architecture-discuss@ietf.org; Tue, 16 Jan 2007 19:38:59 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ypN-0000Yy-U4 for architecture-discuss@ietf.org; Tue, 16 Jan 2007 19:38:59 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l0H0cpKA012345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 16 Jan 2007 18:38:51 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070113225411.GD60501@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [arch-d] 2. thinking about an implementation Date: Tue, 16 Jan 2007 18:38:50 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Jan 13, 2007, at 4:54 PM, John Leslie wrote: >> >> ... Disseminating a lot of state information in and of itself isn't >> immediately fatal if we can avoid having to update it very often or >> having to do lookups on it very fast. I.e., if an edge box that lives >> at 1 Gbps or lower bandwidth only has to encapsulate packets without >> considering reachability because rerouting at the outer header >> protocol takes care of that, it could work well. > > Indeed, edge routers could afford to synchronize more state than > backbone routers can. I'm not sure I agree that edge routers could afford to synchronize more state than backbone routers can. A lot of edge routers might have to be beefed up to contain the state for the whole global routing table and keep up with the churn. Also if churn is really the problem in the core, then moving the churn to the edge doesn't necessarily solve the problem. It may just be moving and delaying the problem, only providing short-term relief. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Jan 17 13:50:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Fq1-000817-Ol; Wed, 17 Jan 2007 13:48:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Fq0-000812-OG for architecture-discuss@ietf.org; Wed, 17 Jan 2007 13:48:44 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Fpz-0001LT-Gg for architecture-discuss@ietf.org; Wed, 17 Jan 2007 13:48:44 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id C71431CC44; Wed, 17 Jan 2007 13:48:43 -0500 (EST) Date: Wed, 17 Jan 2007 13:48:43 -0500 From: John Leslie To: Bruce Curtis Subject: Re: [arch-d] 2. thinking about an implementation Message-ID: <20070117184843.GB85216@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bruce Curtis wrote: > On Jan 13, 2007, at 4:54 PM, John Leslie wrote: >> Iljitsch van Beijnum wrote: >> >>> ... Disseminating a lot of state information in and of itself isn't >>> immediately fatal if we can avoid having to update it very often or >>> having to do lookups on it very fast. I.e., if an edge box that lives >>> at 1 Gbps or lower bandwidth only has to encapsulate packets without >>> considering reachability because rerouting at the outer header >>> protocol takes care of that, it could work well. >> >> Indeed, edge routers could afford to synchronize more state than >> backbone routers can. > > I'm not sure I agree that edge routers could afford to synchronize > more state than backbone routers can. A lot of edge routers might > have to be beefed up to contain the state for the whole global > routing table and keep up with the churn. We're talking architecture: it might indeed be necessary to beef up edge routers. (That's somebody else's problem.) But it shouldn't be necessary for them to hold the "whole global routing table", most of which is of no interest to them. Even if this were necessary, _holding_ a global routing table several orders of magnitude larger than today's "defaultless" tables isn't difficult. It is clearly _not_ necessary for them to keep up with the churn: they're "edge routers" which don't have to pass routes to neighbors. > Also if churn is really the problem in the core, then moving the > churn to the edge doesn't necessarily solve the problem. It may just > be moving and delaying the problem, only providing short-term relief. I don't believe either Iljitsch or I have proposed "moving churn to the edge". Nonetheless "churn at the edge" is a much more scalable issue, IMHO. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Jan 18 06:59:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VuX-0000m2-QY; Thu, 18 Jan 2007 06:58:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VuU-0000gz-C2 for architecture-discuss@ietf.org; Thu, 18 Jan 2007 06:58:26 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Vrj-0005bw-HG for architecture-discuss@ietf.org; Thu, 18 Jan 2007 06:55:36 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0IBtvOi081247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jan 2007 12:55:58 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20070113225411.GD60501@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] 2. thinking about an implementation Date: Thu, 18 Jan 2007 12:55:30 +0100 To: John Leslie X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 13-jan-2007, at 23:54, John Leslie wrote: >>> What's a non-starter is designing around a "flag day". >> It's even worse. Going from IPv4 to IPv6 with a flag day won't work. >> But going from IPv4 to dual stack and then from dual stack to IPv6 >> doesn't work either, even though no flag day is required, because in >> a network the size of the internet it's impossible to complete any >> action that involves changes to every { host | stack | router | AS >> | ... } . There will always be holdouts. > Going from IPv4 to dual-stack _does_ work. (I agree IPv4 won't > disappear anytime soon.) I'm not sure what you mean by "does work". Certainly, it's possible to upgrade stuff from IPv4 to dual stack. But waiting for the whole IPv4 internet to become dual stack before we get to turn off IPv4 isn't a realistic IPv6 deployment scenario. >> The first step is to have edge (customer-facing) routers in ISP >> networks encapsulate and border routers decapsulate in order to make >> packets flow through the core without the core needing to have the >> 90% prefixes that generate 10% of the traffic. > This is a rather big step; and it doesn't feel necessary... Seems like a relatively small step to me... >> The second step is to encapsulate at the source edge and decapsulate >> at the destination edge, so the border routers don't have to see the >> "vanity prefixes" either. > What do you mean by "edge"? (This could be a critical architectural > question.) In general the place where end-user and ISP infrastructures come together, in this particular case the ISP side of it. >> The third step is to optionally have customers encapsulate and/or >> decapsulate. This saves capacity on the ISP edge routers and allows >> the customer equipment to make smarter decisions. > Designing the architecture for this looks like an interesting > problem. A lack of interesting problems to work on would be a bad thing. :-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Jan 18 15:20:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7djM-00077T-RY; Thu, 18 Jan 2007 15:19:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7djK-00075B-2i for architecture-discuss@ietf.org; Thu, 18 Jan 2007 15:19:26 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7djI-0000IU-0E for architecture-discuss@ietf.org; Thu, 18 Jan 2007 15:19:25 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id B01EC1CC19; Thu, 18 Jan 2007 15:19:19 -0500 (EST) Date: Thu, 18 Jan 2007 15:19:19 -0500 From: John Leslie To: Iljitsch van Beijnum Subject: Re: [arch-d] 2. thinking about an implementation Message-ID: <20070118201919.GI16158@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Iljitsch van Beijnum wrote: > On 13-jan-2007, at 23:54, John Leslie wrote: > >> Going from IPv4 to dual-stack _does_ work. (I agree IPv4 won't >> disappear anytime soon.) > > I'm not sure what you mean by "does work". Certainly, it's possible > to upgrade stuff from IPv4 to dual stack. But waiting for the whole > IPv4 internet to become dual stack before we get to turn off IPv4 > isn't a realistic IPv6 deployment scenario. Personally I agree. (It might be appropriate to discuss more practical deployment options...) >> Iljitsch van Beijnum wrote: >> >>> The first step is to have edge (customer-facing) routers in ISP >>> networks encapsulate and border routers decapsulate in order to make >>> packets flow through the core without the core needing to have the >>> 90% prefixes that generate 10% of the traffic. > >> This is a rather big step; and it doesn't feel necessary... > > Seems like a relatively small step to me... Anything that requires coordination of both ends is big, IMHO. >>> The second step is to encapsulate at the source edge and decapsulate >>> at the destination edge, so the border routers don't have to see the >>> "vanity prefixes" either. > >> What do you mean by "edge"? (This could be a critical architectural >> question.) > > In general the place where end-user and ISP infrastructures come > together, in this particular case the ISP side of it. At first blush, this seems a poor choice. There's more benefit to the user than the ISP; and interoperability among mass-market products is likely to be easier to attain than interoperability among one-off kludges by different ISPs. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Jan 20 05:57:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Ds7-0004h5-CA; Sat, 20 Jan 2007 05:54:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Ds5-0004gy-37 for architecture-discuss@ietf.org; Sat, 20 Jan 2007 05:54:53 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Ds3-0005AY-IK for architecture-discuss@ietf.org; Sat, 20 Jan 2007 05:54:53 -0500 Received: from [192.168.2.105] (r74-192-164-23.gtwncmta01.grtntx.tl.dh.suddenlink.net [74.192.164.23]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l0KAsle2006381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 20 Jan 2007 04:54:48 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070117184843.GB85216@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [arch-d] 2. thinking about an implementation Date: Sat, 20 Jan 2007 04:54:21 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Jan 17, 2007, at 12:48 PM, John Leslie wrote: > Bruce Curtis wrote: >> On Jan 13, 2007, at 4:54 PM, John Leslie wrote: >>> Iljitsch van Beijnum wrote: >>> >>>> ... Disseminating a lot of state information in and of itself isn't >>>> immediately fatal if we can avoid having to update it very often or >>>> having to do lookups on it very fast. I.e., if an edge box that >>>> lives >>>> at 1 Gbps or lower bandwidth only has to encapsulate packets >>>> without >>>> considering reachability because rerouting at the outer header >>>> protocol takes care of that, it could work well. >>> >>> Indeed, edge routers could afford to synchronize more state than >>> backbone routers can. >> >> I'm not sure I agree that edge routers could afford to synchronize >> more state than backbone routers can. A lot of edge routers might >> have to be beefed up to contain the state for the whole global >> routing table and keep up with the churn. > > We're talking architecture: it might indeed be necessary to beef up > edge routers. (That's somebody else's problem.) If there are problems with scaling in the core today then solutions that increase state in edge routers might not scale in the future. Architectures that push as much state as possible all the way to the endpoints might scale the best. > But it shouldn't be necessary for them to hold the "whole global > routing table", most of which is of no interest to them. Even if this > were necessary, _holding_ a global routing table several orders of > magnitude larger than today's "defaultless" tables isn't difficult. I might not be following correctly but a lot of proposals have depended on choosing one of several possible destination locators at the edge routers. If the edge routers don't have info about the state of all the links to all multihomed sites it might send packets to a locator that was only reachable on a link that was down. The report on the IAB Workshop on Routing and Addressing mentions that all locator/identifier split proposals must address the problem of detecting locator failures and redirecting data flows to remaining locators for a multihomed site. > It is clearly _not_ necessary for them to keep up with the churn: > they're "edge routers" which don't have to pass routes to neighbors. > >> Also if churn is really the problem in the core, then moving the >> churn to the edge doesn't necessarily solve the problem. It may just >> be moving and delaying the problem, only providing short-term relief. > > I don't believe either Iljitsch or I have proposed "moving churn to > the edge". Sorry, I didn't mean to imply that anyone proposed it exactly that way. That is just a danger that I see in architectures that move the problem of handling "locator failures" from the core routers to the edge routers. I understand how moving to a split locator/identifier and hierarchical routing reduces the size of the routing table but I don't see how it reduces the amount of information about paths to multihomed sites that are down that must be disseminated to either the core routers or the edge routers. > Nonetheless "churn at the edge" is a much more scalable > issue, IMHO. > > -- > John Leslie --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Jan 20 14:27:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Lq9-0007B1-RT; Sat, 20 Jan 2007 14:25:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Lq8-0007At-Lm for architecture-discuss@ietf.org; Sat, 20 Jan 2007 14:25:24 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Lq7-0006y8-Au for architecture-discuss@ietf.org; Sat, 20 Jan 2007 14:25:24 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 38C191CC16; Sat, 20 Jan 2007 14:25:18 -0500 (EST) Date: Sat, 20 Jan 2007 14:25:18 -0500 From: John Leslie To: Bruce Curtis Subject: Re: [arch-d] 2. thinking about an implementation Message-ID: <20070120192518.GJ16158@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bruce Curtis wrote: > On Jan 17, 2007, at 12:48 PM, John Leslie wrote: > > If there are problems with scaling in the core today then solutions > that increase state in edge routers might not scale in the future. > Architectures that push as much state as possible all the way to > the endpoints might scale the best. Yes. >> But it shouldn't be necessary for them to hold the "whole global >> routing table", most of which is of no interest to them. Even if this >> were necessary, _holding_ a global routing table several orders of >> magnitude larger than today's "defaultless" tables isn't difficult. > > I might not be following correctly but a lot of proposals have > depended on choosing one of several possible destination locators at > the edge routers. If the edge routers don't have info about the > state of all the links to all multihomed sites it might send packets > to a locator that was only reachable on a link that was down. I hope we're not seriously conlidering any requirement that a packet in transit deserves to be re-routed if we find its next-hop down. (In fact, I claim the distinction between "congested" and "down" is arbitrary, and that such a distinction should be made by end systems.) > The report on the IAB Workshop on Routing and Addressing mentions > that all locator/identifier split proposals must address the problem > of detecting locator failures and redirecting data flows to remaining > locators for a multihomed site. My view on this is that end systems should evaluate congestion on all options, and migrate traffic to the least congested choice. (YMMV, I suppose...) >> I don't believe either Iljitsch or I have proposed "moving churn to >> the edge". > > Sorry, I didn't mean to imply that anyone proposed it exactly that > way. That is just a danger that I see in architectures that move the > problem of handling "locator failures" from the core routers to the > edge routers. I understand how moving to a split locator/identifier > and hierarchical routing reduces the size of the routing table but I > don't see how it reduces the amount of information about paths to > multihomed sites that are down that must be disseminated to either > the core routers or the edge routers. I'd prefer to move it to end systems, actually. Edge routers _might_ be part of a transition. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Jan 20 17:18:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8OWO-0007t8-RV; Sat, 20 Jan 2007 17:17:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8OWN-0007t3-PH for architecture-discuss@ietf.org; Sat, 20 Jan 2007 17:17:11 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8OWM-0006I7-9s for architecture-discuss@ietf.org; Sat, 20 Jan 2007 17:17:11 -0500 Received: from [192.168.2.105] (r74-192-164-23.gtwncmta01.grtntx.tl.dh.suddenlink.net [74.192.164.23]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l0KMH5RP024325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 20 Jan 2007 16:17:07 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070120192518.GJ16158@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E2EE8ED-1843-4460-8F83-475681982813@ndsu.edu> Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [arch-d] 2. thinking about an implementation Date: Sat, 20 Jan 2007 16:16:39 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Jan 20, 2007, at 1:25 PM, John Leslie wrote: > Bruce Curtis wrote: >> On Jan 17, 2007, at 12:48 PM, John Leslie wrote: >> > > I hope we're not seriously conlidering any requirement that a > packet > in transit deserves to be re-routed if we find its next-hop down. > > (In fact, I claim the distinction between "congested" and "down" is > arbitrary, and that such a distinction should be made by end systems.) I'm not sure about others but I have thought about such options. It helped me think through the issues and differences. But the more I think about it the more it seems that perhaps the endpoint is the better place for such decisions, endpoints today already have to deal with one of multiple addresses associated with a DNS name being down when sessions are initiated. If we put all of the destination locators in a packet then core routers have enough information to re-route if a next-hop is down without requiring state and churn in either the core or edge routers. But there are a few complications required in such a solution such as the core routers rewriting the list of destination locators or at least a bit to mark some as failed etc. It still might be a good idea to consider putting all of the destination locators in a packet for Traffic Engineering but if the end points are responsible for locator failure things are a lot simpler in the core and in the edge. >> The report on the IAB Workshop on Routing and Addressing mentions >> that all locator/identifier split proposals must address the problem >> of detecting locator failures and redirecting data flows to remaining >> locators for a multihomed site. > > My view on this is that end systems should evaluate congestion on > all options, and migrate traffic to the least congested choice. > > (YMMV, I suppose...) I think that it would be an advantage for an architecture to have that option. But to satisfy everyone I think the architecture should also allow the option of traffic engineering at the edge and in the core. >>> I don't believe either Iljitsch or I have proposed "moving churn to >>> the edge". >> >> Sorry, I didn't mean to imply that anyone proposed it exactly that >> way. That is just a danger that I see in architectures that move the >> problem of handling "locator failures" from the core routers to the >> edge routers. I understand how moving to a split locator/identifier >> and hierarchical routing reduces the size of the routing table but I >> don't see how it reduces the amount of information about paths to >> multihomed sites that are down that must be disseminated to either >> the core routers or the edge routers. > > I'd prefer to move it to end systems, actually. Edge routers > _might_ > be part of a transition. > > -- > John Leslie Sounds like the possibility of handling locator failure in the end system is part of the discussion. Thanks. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Jan 21 03:27:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Y0t-0002na-GI; Sun, 21 Jan 2007 03:25:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Y0s-0002nV-AI for architecture-discuss@ietf.org; Sun, 21 Jan 2007 03:25:18 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Y0p-0006Ts-8M for architecture-discuss@ietf.org; Sun, 21 Jan 2007 03:25:18 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0L8PEf8144190 for ; Sun, 21 Jan 2007 08:25:14 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0L8PES43002506 for ; Sun, 21 Jan 2007 09:25:14 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0L8PDer002221 for ; Sun, 21 Jan 2007 09:25:13 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0L8PDS2002212; Sun, 21 Jan 2007 09:25:13 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA74390; Sun, 21 Jan 2007 09:25:11 +0100 Message-ID: <45B32367.1020202@zurich.ibm.com> Date: Sun, 21 Jan 2007 09:25:11 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: John Leslie Subject: Re: [arch-d] 2. thinking about an implementation References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> In-Reply-To: <20070120192518.GJ16158@verdi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 2007-01-20 20:25, John Leslie wrote: > Bruce Curtis wrote: >> On Jan 17, 2007, at 12:48 PM, John Leslie wrote: >> >> If there are problems with scaling in the core today then solutions >> that increase state in edge routers might not scale in the future. >> Architectures that push as much state as possible all the way to >> the endpoints might scale the best. > > Yes. Please note, though, that one of the more interesting criticisms of shim6 is that it asks end systems (e.g. server farms) to hold extra state per session. Moving state around does move heat dissipation around. > >>> But it shouldn't be necessary for them to hold the "whole global >>> routing table", most of which is of no interest to them. Even if this >>> were necessary, _holding_ a global routing table several orders of >>> magnitude larger than today's "defaultless" tables isn't difficult. >> I might not be following correctly but a lot of proposals have >> depended on choosing one of several possible destination locators at >> the edge routers. If the edge routers don't have info about the >> state of all the links to all multihomed sites it might send packets >> to a locator that was only reachable on a link that was down. > > I hope we're not seriously conlidering any requirement that a packet > in transit deserves to be re-routed if we find its next-hop down. > > (In fact, I claim the distinction between "congested" and "down" is > arbitrary, and that such a distinction should be made by end systems.) That sounds plausible, but the real problem is distinguishing "congested" from "lossy", because that dramatically affects how a transport protocol should react - slow down in the case of "congested", rapid retransmit in the case of "lossy". Brian > >> The report on the IAB Workshop on Routing and Addressing mentions >> that all locator/identifier split proposals must address the problem >> of detecting locator failures and redirecting data flows to remaining >> locators for a multihomed site. > > My view on this is that end systems should evaluate congestion on > all options, and migrate traffic to the least congested choice. > > (YMMV, I suppose...) > >>> I don't believe either Iljitsch or I have proposed "moving churn to >>> the edge". >> Sorry, I didn't mean to imply that anyone proposed it exactly that >> way. That is just a danger that I see in architectures that move the >> problem of handling "locator failures" from the core routers to the >> edge routers. I understand how moving to a split locator/identifier >> and hierarchical routing reduces the size of the routing table but I >> don't see how it reduces the amount of information about paths to >> multihomed sites that are down that must be disseminated to either >> the core routers or the edge routers. > > I'd prefer to move it to end systems, actually. Edge routers _might_ > be part of a transition. > > -- > John Leslie > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Jan 21 08:24:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ceX-0003cF-Ii; Sun, 21 Jan 2007 08:22:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ceW-0003aw-Bm for architecture-discuss@ietf.org; Sun, 21 Jan 2007 08:22:32 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8cb6-00076N-GR for architecture-discuss@ietf.org; Sun, 21 Jan 2007 08:19:02 -0500 Received: from s73602 ([72.190.0.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20070121131855.MNU28374.mta10.adelphia.net@s73602> for ; Sun, 21 Jan 2007 08:18:55 -0500 Message-ID: <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu><20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> Subject: Re: [arch-d] 2. thinking about an implementation Date: Sun, 21 Jan 2007 07:18:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org OK, we've been here before, too. >> (In fact, I claim the distinction between "congested" and "down" is >> arbitrary, and that such a distinction should be made by end systems.) > > That sounds plausible, but the real problem is distinguishing "congested" > from "lossy", because that dramatically affects how a transport > protocol should react - slow down in the case of "congested", rapid > retransmit in the case of "lossy". We have about thirty years of experience (which I missed the first tweny years of, but which people then spent ten years reminding me about) with trying to distinguish between congestion and corruption, and responding accordingly. We made this harder for ourselves than it had to be with TCP (one indication that there's a problem - packet loss - and two problems that can cause that indication - congestion, and corruption). Adding explicit congestion notification (ECN) helps (potentially), but not as much as we might hope - we don't know how to convey ECN at very high congestion levels, so an endpoint can tell that there is congestion if ECN IS set, but can't interpret the lack of ECN-marked traffic as an absence of congestion, since all the ECN-marked packets could have been discarded due to congestion - this would be the precise wrong time to rapidly retransmit. We have dorked around with explicit error notification, but since bit errors may be present in the IP header fields, it's not precisely obvious where to send explicit error notifications ("I received an errored packet with your IP address as source, but you might not have sent it, because the packet didn't pass checksum processing"). We try to be conservative (having previously tried "when you get a timeout, feel free to retransmit all outstanding packets" and experiencing the resulting meltdown - Dave Clark referred to this as the "kick 'em when they're down" school of transport retransmission), and the problem here is that if you spend a few RTTs trying to be conservative, you end up recovering about as quickly if you assume that everything is congestion as you do with any other strategy. Perhaps some careful thought on transport might be part of a new architecture? We talked about this at the TERNLI ad hoc meeting in Montreal, and Sally and Pasi produced draft-sarolahti-tsvwg-crosslayer-00.txt, but I haven't seen anything past that... Spencer p.s. the crosslayer draft does a better job of characterizing IETF work in this space in Section 5 - the above is just my recollection... _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Jan 21 10:16:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ePp-0007b9-2u; Sun, 21 Jan 2007 10:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8ePo-0007b4-2R for architecture-discuss@ietf.org; Sun, 21 Jan 2007 10:15:28 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8ePl-0006JE-MX for architecture-discuss@ietf.org; Sun, 21 Jan 2007 10:15:28 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 5CE74C20C for ; Sun, 21 Jan 2007 10:15:22 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0LFFLPW011079; Sun, 21 Jan 2007 10:15:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0LFFG3g021980; Sun, 21 Jan 2007 10:15:16 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 1tEuEaLUxmFf; Sun, 21 Jan 2007 10:15:16 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0LFFDDZ021971;Sun, 21 Jan 2007 10:15:13 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id BDA784FD8E; Sun, 21 Jan 2007 10:12:48 -0500 (EST) Date: Sun, 21 Jan 2007 10:12:48 -0500 From: Wesley Eddy To: Spencer Dawkins Subject: Re: [arch-d] 2. thinking about an implementation Message-ID: <20070121151248.GA27893@grc.nasa.gov> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Sun, Jan 21, 2007 at 07:18:55AM -0600, Spencer Dawkins wrote: > > We have dorked around with explicit error notification, but since bit > errors may be present in the IP header fields, it's not precisely obvious > where to send explicit error notifications ("I received an errored packet > with your IP address as source, but you might not have sent it, because the > packet didn't pass checksum processing"). To get around this, we've also tried explicit error _rate_ notification, so we don't have to know exactly who to send an error report for a particular errored packet to. Congestion control based on the relative congestion and corruption rates to the total loss rate seems to work nicely. Of course, this requires some router support. Two references: http://www.icir.org/mallman/papers/eten-comnet.ps Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig Partridge, Mark Allman. Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks. Computer Networks, 46(3), October 2004. http://www.icir.org/mallman/papers/ceten-ccr-oct2004.ps Wesley Eddy, Shawn Ostermann, Mark Allman. New Techniques for Making Transport Protocols Robust to Corruption-Based Loss. ACM Computer Communication Review, 34(5), October 2004. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Jan 21 12:47:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8glS-0004p8-Ci; Sun, 21 Jan 2007 12:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8glR-0004p3-FS for architecture-discuss@ietf.org; Sun, 21 Jan 2007 12:45:57 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8glQ-0005xa-4r for architecture-discuss@ietf.org; Sun, 21 Jan 2007 12:45:57 -0500 Received: from [192.168.0.41] (pool-141-153-190-218.mad.east.verizon.net [141.153.190.218]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0LHji9F022410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 21 Jan 2007 12:45:49 -0500 (EST) In-Reply-To: <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu><20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55A85002-5A1E-4AE0-A99A-D2937212FE3F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [arch-d] 2. thinking about an implementation Date: Sun, 21 Jan 2007 12:45:41 -0500 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I'm not sure how practically relevant corruption loss is outside some corner cases: - Extremely high speed TCP connections, where even bit error rates of 10e-12 matter and thus normal error detection mechanisms don't work well any more and where even very rare losses cause havoc with the congestion control algorithm; - Specialty links, such as deep-space satellites - 3G radio links when configured for packet audio (but these wouldn't be used for TCP-like protocols, one would hope) Are there modern, commonly-occurring links that don't retransmit errored packet locally for data traffic and have significant error rates? Henning On Jan 21, 2007, at 8:18 AM, Spencer Dawkins wrote: > OK, we've been here before, too. > >>> (In fact, I claim the distinction between "congested" and >>> "down" is >>> arbitrary, and that such a distinction should be made by end >>> systems.) >> >> That sounds plausible, but the real problem is distinguishing >> "congested" >> from "lossy", because that dramatically affects how a transport >> protocol should react - slow down in the case of "congested", rapid >> retransmit in the case of "lossy". > > We have about thirty years of experience (which I missed the first > tweny years of, but which people then spent ten years reminding me > about) with trying to distinguish between congestion and > corruption, and responding accordingly. > > We made this harder for ourselves than it had to be with TCP (one > indication that there's a problem - packet loss - and two problems > that can cause that indication - congestion, and corruption). > > Adding explicit congestion notification (ECN) helps (potentially), > but not as much as we might hope - we don't know how to convey ECN > at very high congestion levels, so an endpoint can tell that there > is congestion if ECN IS set, but can't interpret the lack of ECN- > marked traffic as an absence of congestion, since all the ECN- > marked packets could have been discarded due to congestion - this > would be the precise wrong time to rapidly retransmit. > > We have dorked around with explicit error notification, but since > bit errors may be present in the IP header fields, it's not > precisely obvious where to send explicit error notifications ("I > received an errored packet with your IP address as source, but you > might not have sent it, because the packet didn't pass checksum > processing"). > > We try to be conservative (having previously tried "when you get a > timeout, feel free to retransmit all outstanding packets" and > experiencing the resulting meltdown - Dave Clark referred to this > as the "kick 'em when they're down" school of transport > retransmission), and the problem here is that if you spend a few > RTTs trying to be conservative, you end up recovering about as > quickly if you assume that everything is congestion as you do with > any other strategy. > > Perhaps some careful thought on transport might be part of a new > architecture? > > We talked about this at the TERNLI ad hoc meeting in Montreal, and > Sally and Pasi produced draft-sarolahti-tsvwg-crosslayer-00.txt, > but I haven't seen anything past that... > > Spencer > > p.s. the crosslayer draft does a better job of characterizing IETF > work in this space in Section 5 - the above is just my recollection... > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Jan 21 17:10:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8krN-0006lh-OM; Sun, 21 Jan 2007 17:08:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8krM-0006kd-Fk for architecture-discuss@ietf.org; Sun, 21 Jan 2007 17:08:20 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8krK-0007Sh-Mh for architecture-discuss@ietf.org; Sun, 21 Jan 2007 17:08:20 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id LAA08692; Mon, 22 Jan 2007 11:08:11 +1300 In-Reply-To: <55A85002-5A1E-4AE0-A99A-D2937212FE3F@cs.columbia.edu> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu><20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> <55A85002-5A1E-4AE0-A99A-D2937212FE3F@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8CB79CDC-288F-4614-8DE5-EB43810C62C1@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [arch-d] 2. thinking about an implementation Date: Mon, 22 Jan 2007 11:09:38 +1300 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Network-encoded mesh wireless systems will be becoming available soon, and they do have the property of not doing local retransmit (because noone inside the subnet has the whole packet, except the source and the edge router). If things are working badly the error rate could be pretty high too, although you'd hope that doesn't happen often. Andrew On 22/01/2007, at 6:45 AM, Henning Schulzrinne wrote: > I'm not sure how practically relevant corruption loss is outside > some corner cases: > > - Extremely high speed TCP connections, where even bit error rates > of 10e-12 matter and thus normal error detection mechanisms don't > work well any more and where even very rare losses cause havoc with > the congestion control algorithm; > > - Specialty links, such as deep-space satellites > > - 3G radio links when configured for packet audio (but these > wouldn't be used for TCP-like protocols, one would hope) > > Are there modern, commonly-occurring links that don't retransmit > errored packet locally for data traffic and have significant error > rates? > > Henning > > On Jan 21, 2007, at 8:18 AM, Spencer Dawkins wrote: > >> OK, we've been here before, too. >> >>>> (In fact, I claim the distinction between "congested" and >>>> "down" is >>>> arbitrary, and that such a distinction should be made by end >>>> systems.) >>> >>> That sounds plausible, but the real problem is distinguishing >>> "congested" >>> from "lossy", because that dramatically affects how a transport >>> protocol should react - slow down in the case of "congested", rapid >>> retransmit in the case of "lossy". >> >> We have about thirty years of experience (which I missed the first >> tweny years of, but which people then spent ten years reminding me >> about) with trying to distinguish between congestion and >> corruption, and responding accordingly. >> >> We made this harder for ourselves than it had to be with TCP (one >> indication that there's a problem - packet loss - and two problems >> that can cause that indication - congestion, and corruption). >> >> Adding explicit congestion notification (ECN) helps (potentially), >> but not as much as we might hope - we don't know how to convey ECN >> at very high congestion levels, so an endpoint can tell that there >> is congestion if ECN IS set, but can't interpret the lack of ECN- >> marked traffic as an absence of congestion, since all the ECN- >> marked packets could have been discarded due to congestion - this >> would be the precise wrong time to rapidly retransmit. >> >> We have dorked around with explicit error notification, but since >> bit errors may be present in the IP header fields, it's not >> precisely obvious where to send explicit error notifications ("I >> received an errored packet with your IP address as source, but you >> might not have sent it, because the packet didn't pass checksum >> processing"). >> >> We try to be conservative (having previously tried "when you get a >> timeout, feel free to retransmit all outstanding packets" and >> experiencing the resulting meltdown - Dave Clark referred to this >> as the "kick 'em when they're down" school of transport >> retransmission), and the problem here is that if you spend a few >> RTTs trying to be conservative, you end up recovering about as >> quickly if you assume that everything is congestion as you do with >> any other strategy. >> >> Perhaps some careful thought on transport might be part of a new >> architecture? >> >> We talked about this at the TERNLI ad hoc meeting in Montreal, and >> Sally and Pasi produced draft-sarolahti-tsvwg-crosslayer-00.txt, >> but I haven't seen anything past that... >> >> Spencer >> >> p.s. the crosslayer draft does a better job of characterizing IETF >> work in this space in Section 5 - the above is just my >> recollection... >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Jan 21 21:22:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8onS-0000HH-Nn; Sun, 21 Jan 2007 21:20:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8onR-0000GR-Fc for Architecture-discuss@ietf.org; Sun, 21 Jan 2007 21:20:33 -0500 Received: from smtp19.orange.fr ([80.12.242.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8onC-0006tr-UX for Architecture-discuss@ietf.org; Sun, 21 Jan 2007 21:20:33 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1917.orange.fr (SMTP Server) with ESMTP id 2F7941C000A4 for ; Mon, 22 Jan 2007 03:20:10 +0100 (CET) Received: from will.lan (LPuteaux-151-41-30-75.w217-128.abo.wanadoo.fr [217.128.82.75]) by mwinf1917.orange.fr (SMTP Server) with ESMTP id E65581C00089 for ; Mon, 22 Jan 2007 03:20:09 +0100 (CET) X-ME-UUID: 20070122022009943.E65581C00089@mwinf1917.orange.fr From: Guillaume FORTAINE Organization: Power.org To: Architecture-discuss@ietf.org Date: Mon, 22 Jan 2007 03:19:56 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701220319.56360.guillaume.fortaine@wanadoo.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [arch-d] Next Generation Networks X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Misters, Happy New year to you :) ! Let me introduce myself : Guillaume FORTAINE, French engineer in informatics. I found your research projects because I am currently researching people with a strong background in Networking. I would want to start a project to develop a new standard a la 802.20 but without repeating/or correcting the past error from IPv6 ( included in MAC/PHY layer of 802.20). Dr. Jose Morales Barroso from L&M Data Communications sent me this link andI believe of interest for you the following paper, presented at the last eChallenges Conference: http://www.lmdata.es/uets/eChallenges-e2006-uets-paper.pdf To quote : "Your comments are welcomed." I look forward to your answer, Best Regards, Guillaume _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Jan 21 23:35:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8qsw-0003zn-7D; Sun, 21 Jan 2007 23:34:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8qsv-0003zi-6W for architecture-discuss@ietf.org; Sun, 21 Jan 2007 23:34:21 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8qst-0001ku-Vd for architecture-discuss@ietf.org; Sun, 21 Jan 2007 23:34:21 -0500 Received: from s73602 ([72.190.0.23]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20070122043419.LHMG20139.mta9.adelphia.net@s73602> for ; Sun, 21 Jan 2007 23:34:19 -0500 Message-ID: <01f801c73dde$930a0550$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu><20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> <55A85002-5A1E-4AE0-A99A-D2937212FE3F@cs.columbia.edu> <8CB79CDC-288F-4614-8DE5-EB43810C62C1@indranet.co.nz> Subject: Re: [arch-d] 2. thinking about an implementation Date: Sun, 21 Jan 2007 22:34:15 -0600 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Network-encoded mesh wireless systems will be becoming available soon, > and they do have the property of not doing local retransmit (because > noone inside the subnet has the whole packet, except the source and the > edge router). If things are working badly the error rate could be pretty > high too, although you'd hope that doesn't happen often. > > Andrew Oh, goody! This sounds like a wonderful place to run current reliable transport protocols :-) But, in response to Henning's note... Another issue in Trigtran (which I can talk about with some confidence) was also that once you lose a link and the sender has gone through a few wait-twice-as-long-and-retry-again cycles, it also takes a while after a link comes back up before the sender figures that out. So this wasn't just a throughput question, it also involved how quickly you respond to changes in the set of potential paths. I can't promise that the world won't be so overdeployed with WiMax that you'll never be somewhere that you can't send and receive traffic, but so far, this has not been my experience :-) Spencer > On 22/01/2007, at 6:45 AM, Henning Schulzrinne wrote: > >> I'm not sure how practically relevant corruption loss is outside some >> corner cases: >> >> - Extremely high speed TCP connections, where even bit error rates of >> 10e-12 matter and thus normal error detection mechanisms don't work well >> any more and where even very rare losses cause havoc with the congestion >> control algorithm; >> >> - Specialty links, such as deep-space satellites >> >> - 3G radio links when configured for packet audio (but these wouldn't be >> used for TCP-like protocols, one would hope) >> >> Are there modern, commonly-occurring links that don't retransmit errored >> packet locally for data traffic and have significant error rates? >> >> Henning _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Jan 22 02:57:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8u21-00057k-4S; Mon, 22 Jan 2007 02:55:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8u1z-00057Z-AW for architecture-discuss@ietf.org; Mon, 22 Jan 2007 02:55:55 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8u1x-0001z3-UP for architecture-discuss@ietf.org; Mon, 22 Jan 2007 02:55:55 -0500 Received: from [192.168.2.105] (r74-192-164-23.gtwncmta01.grtntx.tl.dh.suddenlink.net [74.192.164.23]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l0M7tonF010028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 22 Jan 2007 01:55:51 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45B32367.1020202@zurich.ibm.com> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5047E9A6-21B8-4F90-80FC-F4EBC94C49AF@ndsu.edu> Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [arch-d] 2. thinking about an implementation Date: Mon, 22 Jan 2007 01:55:22 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Jan 21, 2007, at 2:25 AM, Brian E Carpenter wrote: > On 2007-01-20 20:25, John Leslie wrote: >> Bruce Curtis wrote: >>> On Jan 17, 2007, at 12:48 PM, John Leslie wrote: >>> >>> If there are problems with scaling in the core today then solutions >>> that increase state in edge routers might not scale in the future. >>> Architectures that push as much state as possible all the way to >>> the endpoints might scale the best. >> Yes. > > Please note, though, that one of the more interesting criticisms > of shim6 is that it asks end systems (e.g. server farms) to > hold extra state per session. Moving state around does move > heat dissipation around. It would seem to me that if the state is too much for servers in server farms to handle then it would likely be too much for the edge router for the server farm to handle also. But I don't run server farms so am far from an expert on the topic. If the server farm folks think it would be preferable to have the state in the edge router or a middle box it would be nice if the architecture allowed that option without too much difficulty but personally I would prefer to consider the server farms a special case and have the default to be to handle the state in the endpoints. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Jan 22 10:47:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91NP-0008DA-8M; Mon, 22 Jan 2007 10:46:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91NN-0008D2-1o for architecture-discuss@ietf.org; Mon, 22 Jan 2007 10:46:29 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H91NL-0005ou-OR for architecture-discuss@ietf.org; Mon, 22 Jan 2007 10:46:29 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id D91461CC1A; Mon, 22 Jan 2007 10:46:25 -0500 (EST) Date: Mon, 22 Jan 2007 10:46:25 -0500 From: John Leslie To: Spencer Dawkins Message-ID: <20070122154625.GK16158@verdi> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <45B32367.1020202@zurich.ibm.com> <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: architecture-discuss@ietf.org Subject: [arch-d] thinking about "congestion" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Spencer Dawkins wrote: > [Brian Carpenter wrote:] >> [John Leslie wrote:] > >>> (In fact, I claim the distinction between "congested" and "down" is >>> arbitrary, and that such a distinction should be made by end systems.) >> >> That sounds plausible, but the real problem is distinguishing "congested" >> from "lossy", because that dramatically affects how a transport >> protocol should react - slow down in the case of "congested", rapid >> retransmit in the case of "lossy". > > We made this harder for ourselves than it had to be with TCP (one > indication that there's a problem - packet loss - and two problems that > can cause that indication - congestion, and corruption). (Actually, "at least two"...) > Adding explicit congestion notification (ECN) helps (potentially), but > not as much as we might hope - Alas, I'm not even sure "ECN" helps. :^( We've got to _start_ by measuring "congestion", not measuring "packet loss" and calling it congestion. ECN, IMHO, didn't go far enough in that direction. RFC3168 defines ECN as " " a congestion indication for incipient congestion (as in RED and " earlier work [RJ90]) where the notification can sometimes be through " marking packets rather than dropping them. which, IMHO, implies that it's a last-ditch effort to avoid signaling "congestion" by dropping a packet. I can't bring myself to call that "measuring" congestion. > we don't know how to convey ECN at very high congestion levels, so an > endpoint can tell that there is congestion if ECN IS set, but can't > interpret the lack of ECN-marked traffic as an absence of congestion... To be fair, ECN (though misnamed IMHO) tried only to be an additional tool in our bag-o-tricks to detect congestion. The absence of ECN-marked packets, clearly, should not be taken to mean anything at all. > We have dorked around with explicit error notification, but since bit > errors may be present in the IP header fields, it's not precisely > obvious where to send explicit error notifications ("I received an > errored packet with your IP address as source, but you might not have > sent it, because the packet didn't pass checksum processing"). IP contains a computationally cheap error indication (checksum). It _is_ obvious, actually, where an IP error indication should be sent: to whatever machine forwarded it to you. (It's not obvious, OTOH, that there's any point in sending it...) > We try to be conservative (having previously tried "when you get a > timeout, feel free to retransmit all outstanding packets" and > experiencing the resulting meltdown... ;^(( > the problem here is that if you spend a few RTTs trying to be > conservative, you end up recovering about as quickly if you assume > that everything is congestion as you do with any other strategy. ... in the absence of actual measurement of congestion, that is... > Perhaps some careful thought on transport might be part of a new > architecture? I certainly hope so! > We talked about this at the TERNLI ad hoc meeting in Montreal, and Sally > and Pasi produced draft-sarolahti-tsvwg-crosslayer-00.txt, but I haven't > seen anything past that... A lot of good summary in that, but the title is unfortunate, giving the impression that we must look to layering invasions for a solution. I found draft-briscoe-tsvwg-re-ecn-tcp particularly interesting... -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Jan 22 12:57:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93Of-0005f0-DA; Mon, 22 Jan 2007 12:55:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93Oe-0005cV-Sw for architecture-discuss@ietf.org; Mon, 22 Jan 2007 12:55:56 -0500 Received: from diotima.switch.ch ([130.59.4.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H93Ob-0002tw-BR for architecture-discuss@ietf.org; Mon, 22 Jan 2007 12:55:54 -0500 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.13.8+Sun/8.13.8) with ESMTP id l0MHobqV012381; Mon, 22 Jan 2007 18:50:37 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.13.8+Sun/8.13.8/Submit) id l0MHoaGM012380; Mon, 22 Jan 2007 18:50:36 +0100 (CET) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@limmat.switch.ch using -f From: Simon Leinen To: Brian E Carpenter Subject: Re: [arch-d] 2. thinking about an implementation In-Reply-To: <45B32367.1020202@zurich.ibm.com> (Brian E. Carpenter's message of "Sun, 21 Jan 2007 09:25:11 +0100") References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Mon, 22 Jan 2007 18:50:36 +0100 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian E Carpenter writes: > Please note, though, that one of the more interesting criticisms of > shim6 is that it asks end systems (e.g. server farms) to hold extra > state per session. Moving state around does move heat dissipation > around. What amount of additional state are we talking about? I don't know shim6 well enough to assess this, but my gut feeling says this cannot be a showstopper. Servers already store quite a big of per-client (even per-connection) state, typically in the form of TCP state including retransmission buffers, which will have to be quite large if clients can be far away and high per-session throughput is desired. I would be very surprised if shim6 support would add significantly to state requirements if TCP is used. And even where additional server state for multihoming clients is prohibitive (maybe for popular DNS servers that mostly use UDP), I think this should be solvable by servers refusing to store clients' shim6 state beyond the absolutely necessary. This would deny seamless failover, but since such protocols won't have valuable state this shouldn't hurt too much. So, I cannot see why something like shim6 shouldn't work with busy servers. (I also agree with Bruce Curtis' points.) -- Simon. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Jan 22 14:17:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H94dx-0003Dy-73; Mon, 22 Jan 2007 14:15:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H94dv-0003Dc-EX for architecture-discuss@ietf.org; Mon, 22 Jan 2007 14:15:47 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H94du-00061s-1h for architecture-discuss@ietf.org; Mon, 22 Jan 2007 14:15:47 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B7F7819876D; Mon, 22 Jan 2007 21:15:42 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6D66119876C; Mon, 22 Jan 2007 21:15:42 +0200 (EET) Message-ID: <45B50D5F.4090403@piuha.net> Date: Mon, 22 Jan 2007 21:15:43 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Simon Leinen Subject: Re: [arch-d] 2. thinking about an implementation References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Simon, > > What amount of additional state are we talking about? The amount of state seems relatively small -- basically session identifiers, upper layer identifiers, locators, security information, and some administrative pieces of information such as generation counters for the latest list of current locators, retransmission timers for control messages, etc. Details in draft-ietf-shim6-proto, Section 6.1. For other host based mechanisms these numbers may vary quite a bit. HIP, for instance, needs more memory because it does more, e.g., establishes end-to-end ESP state. Of course, if you multiply this amount of state information by a large number of clients, you may need a lot of memory to hold the state and a lot of signaling to set it up. In any case, perhaps more important issues are whether this information is needed for all communications, and who gets to decide whether the state has to be registered. Holding state in the DNS server for its clients seems silly, for instance, if the transactions consist of one message and a reply. It may make more sense to send a new message after a re-homing event than to try to keep the server aware of your situation. The same may apply to other applications too. It also seems important that whoever is requested to spend effort or keep state has a say in whether they are willing to do so. My understanding is that this is what is done in all host based mechanisms to date, i.e., the peer can refuse to keep your multihoming state. Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Jan 23 08:29:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9LhI-0004ft-Pn; Tue, 23 Jan 2007 08:28:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9LhI-0004fg-4Z for architecture-discuss@ietf.org; Tue, 23 Jan 2007 08:28:24 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9LhG-0001NI-NC for architecture-discuss@ietf.org; Tue, 23 Jan 2007 08:28:24 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0NDSJB1091532 for ; Tue, 23 Jan 2007 13:28:19 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0NDSJLb3256444 for ; Tue, 23 Jan 2007 14:28:19 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0NDSI7E011908 for ; Tue, 23 Jan 2007 14:28:18 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0NDSIUh011893; Tue, 23 Jan 2007 14:28:18 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA338828; Tue, 23 Jan 2007 14:28:17 +0100 Message-ID: <45B60D71.1030206@zurich.ibm.com> Date: Tue, 23 Jan 2007 14:28:17 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Simon Leinen Subject: Re: [arch-d] 2. thinking about an implementation References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu> <20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 2007-01-22 18:50, Simon Leinen wrote: > Brian E Carpenter writes: >> Please note, though, that one of the more interesting criticisms of >> shim6 is that it asks end systems (e.g. server farms) to hold extra >> state per session. Moving state around does move heat dissipation >> around. > > What amount of additional state are we talking about? I like Jari's answer, but I would suggest another way to look at it: instead of the site NAT (or PAT) having to hold state per active flow, each host will have to hold state per active flow. So the border box will get noticeably less hot and (in a server farm) the offload NICs will each get a little hotter. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Jan 23 09:12:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MMZ-0007y5-2w; Tue, 23 Jan 2007 09:11:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MMY-0007xs-3V for architecture-discuss@ietf.org; Tue, 23 Jan 2007 09:11:02 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9MMT-0007lC-Mq for architecture-discuss@ietf.org; Tue, 23 Jan 2007 09:11:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 0ED4F26C21D; Tue, 23 Jan 2007 15:10:55 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E773926C158; Tue, 23 Jan 2007 15:10:54 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id DA75558EDCA; Tue, 23 Jan 2007 15:10:54 +0100 (CET) Date: Tue, 23 Jan 2007 15:10:54 +0100 From: Stephane Bortzmeyer To: Iljitsch van Beijnum Subject: Re: [arch-d] 1. the architecture Message-ID: <20070123141054.GA451@nic.fr> References: <20070112205231.GB60501@verdi> <3D5492AF-A126-42E0-92AA-F26821D5D97A@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5492AF-A126-42E0-92AA-F26821D5D97A@muada.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Fri, Jan 12, 2007 at 11:52:49PM +0100, Iljitsch van Beijnum wrote a message of 82 lines which said: > Proxies is exactly what I had in mind. Because HTTP proxies see the > real identifier and not just the one implied by the destination > address, they can do much more than a NAT box. But I only want this > at setup. Once that's done, packets should flow with minimal > processing by intermediate devices. Isn't it the architecture of OPES? (RFC 3835). Once the complicated things are done in the "callout server", the data flow only goes through the OPES processor. It seems OPES addresses most of your needs. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Jan 29 11:44:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZaK-0003oF-Ki; Mon, 29 Jan 2007 11:42:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZaJ-0003o9-Jl for architecture-discuss@ietf.org; Mon, 29 Jan 2007 11:42:23 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZaJ-0003rZ-9T for architecture-discuss@ietf.org; Mon, 29 Jan 2007 11:42:23 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0TGgYJE017829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jan 2007 17:42:35 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> References: <81821261-958E-490C-A713-5BFC0EBFF01F@muada.com> <20070112212309.GC60501@verdi> <900ABCA8-8561-4A10-842F-5398BD92ECE6@muada.com> <20070113225411.GD60501@verdi> <20070117184843.GB85216@verdi> <85BE5971-34A0-4D88-9E66-5164EA3A0847@ndsu.edu><20070120192518.GJ16158@verdi> <45B32367.1020202@zurich.ibm.com> <01aa01c73d5e$b4203be0$6501a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <313A4853-B646-49F8-A863-F154171FDFCE@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [arch-d] 2. thinking about an implementation Date: Mon, 29 Jan 2007 17:42:15 +0100 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 21-jan-2007, at 14:18, Spencer Dawkins wrote: > We have about thirty years of experience (which I missed the first > tweny years of, but which people then spent ten years reminding me > about) with trying to distinguish between congestion and > corruption, and responding accordingly. You are looking at the symptom rather than the disease. The real problem is lack of data flow. Both having congestion and trying to avoid congestion cause this, and when packet loss is the result of errors, trying to avoid congestion doesn't help either. I think we've reached the point where trying to avoid congestion is doing more harm than good. (See all the work on long fat pipes and more aggressive TCP ramp up.) It would be so much easier if we could just have a "discard eligible" bit and be done with it. Note by the way that most errors cause only a single lost packet once in a while so fast retransmit will catch most of those. If you keep losing multiple successive packets because of errors you may want to spend time on something other than TCP performance. > Perhaps some careful thought on transport might be part of a new > architecture? TCP is too stupid. It knows nothing about timing and uses windows to make everything work. Maybe if I have a 1 Gbps link to a router with a 100 Mbps uplink, it is be a good idea to send packets at 100 Mbps rather than burst at 1 Gbps 1/10th of the time? For a while we had a buffer arms race between routers and TCP, but TCP won because the routers got too fast. What I mean is that ideally, TCP buffers should be equal to the bandwidth/delay product. But they're often much larger, so traffic is burstier than necessary. In order to accommodate the bursts, routers have large buffer pools. But at 10 Gbps this is an expensive proposition so routers can't accommodate TCP's excessive burstiness under all circumstances. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Jan 30 12:20:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwcr-00085u-9J; Tue, 30 Jan 2007 12:18:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwcq-00085p-Ge for architecture-discuss@ietf.org; Tue, 30 Jan 2007 12:18:32 -0500 Received: from ndjsvws04.ndc.nasa.gov ([198.120.25.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwcj-0005nd-LW for architecture-discuss@ietf.org; Tue, 30 Jan 2007 12:18:32 -0500 Received: from ndjsxgw02.ndc.nasa.gov ([129.166.32.112]) by ndjsvws04.ndc.nasa.gov with InterScan Messaging Security Suite; Tue, 30 Jan 2007 11:18:23 -0600 Received: from NDJSEVS15.ndc.nasa.gov ([129.166.32.125]) by ndjsxgw02.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 11:18:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jan 2007 11:18:11 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of IPv6 Addressing for QoS Thread-Index: AcdEkp56HbzwzxxZTxGzdDZizTxNrg== From: "Ivancic, William D. \(GRC-RCN0\)" To: X-OriginalArrivalTime: 30 Jan 2007 17:18:18.0727 (UTC) FILETIME=[A29A1770:01C74492] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [arch-d] Use of IPv6 Addressing for QoS X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I am starting to see a very large amount of discussion of using IPv6 addressing for QoS. The thought process seems to be that there is infinite IPv6 address space and that one can basically set up different networks for QoS. It may be easier to manage network address rather than using the QoS bits available in IPv6. A similar thought process appears to be happening with security. To me separating network for things like air traffic control versus entertainment makes perfect sense. Separating networks for QoS or security level may be an attractive and easy solution, but I question that this is proper use of address space. =20 The following are just some examples taken from some recent emails and other work: "One thought that came to mind was to distribute IPv6 addresses based on the class of/quality of service required. VOIP would get one range of addresses, non real-time data another, etc... " "IP-v6 Drivers for Aviation & Usage Concepts, "Power Point, file size 1.124 Mbytes) See slides 8 and 9 http://roland.grc.nasa.gov/~ivancic/papers_presentations/2007/IPv6-Drive rs_and_Concepts_for_the_Aviation_Industry_Eurocontrol.ppt Comment: To me separating network for things like air traffic control versus entertainment makes perfect sense. Separating networks for QoS may be an attractive and easy solution, but I question that this is proper use of address space. EUROCONTROL IPv6 Addressing and Autonomous System Numbers," International Civil Aviation Organization (ICAO) Aeronautical Communications Panel (ACP) Sub-Working Group N-1 Working Paper 1108, 09 Nov 2006.=20 http://roland.grc.nasa.gov/~ivancic/papers_presentations/2007/WP1108%20E UROCONTROL%20IPv6%20ASN%20Addressing_final.doc (MS Word Document, file size 332 kbytes) Comment: This appears to be proper use of network addresses, but with quite a large amount of wasted space. =20 ****************************** Will Ivancic _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Jan 31 00:13:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7jP-0001cH-Dp; Wed, 31 Jan 2007 00:10:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7jN-0001bj-Lr for architecture-discuss@ietf.org; Wed, 31 Jan 2007 00:10:01 -0500 Received: from neo-u2.ops-netman.net ([2001:408:1009:1:2d0:a8ff:fe00:4bc4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC7jL-0002yd-Ak for architecture-discuss@ietf.org; Wed, 31 Jan 2007 00:10:01 -0500 Received: from [IPv6?2001?408?1009?2?211?24ff?fea9?7105] (en1.russian-fingers.as701.net [IPv6:2001:408:1009:2:211:24ff:fea9:7105]) by neo-u2.ops-netman.net (Postfix) with ESMTP id 328552249; Wed, 31 Jan 2007 05:09:42 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6464C6A5-8103-458E-9F31-430AB6ECD64D@ops-netman.net> Content-Transfer-Encoding: 7bit From: Chris Morrow Subject: Re: [arch-d] Use of IPv6 Addressing for QoS Date: Wed, 31 Jan 2007 00:09:40 -0500 To: "Ivancic, William D. (GRC-RCN0)" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Jan 30, 2007, at 12:18 PM, Ivancic, William D. (GRC-RCN0) wrote: > > I am starting to see a very large amount of discussion of using IPv6 > addressing for QoS. The thought process seems to be that there is > infinite IPv6 address space and that one can basically set up > different > networks for QoS. It may be easier to manage network address rather > than using the QoS bits available in IPv6. A similar thought process > appears to be happening with security. > > To me separating network for things like air traffic control versus > entertainment makes perfect sense. Separating networks for QoS or > security level may be an attractive and easy solution, but I question > that this is proper use of address space. > so what? address space in v6 is 'unlimited' There are examples today in the v4 world of 'seperate networks' for voice, video, data... how is that different than the proposed v6 networks above? It seems perfectly fine (to me atleast) that people might want to make a 'seperate network' for voice, video, private-ip- data .... should we actively work to thwart that? would it do any good? Perhaps they have more than a managable (in a v4 sense) number of managed endpoints to deal with and v6 seems like it'd give them management headroom? > > The following are just some examples taken from some recent emails and > other work: > > "One thought that came to mind was to distribute IPv6 addresses > based on > the class of/quality of service required. VOIP would get one range of > addresses, non real-time data another, etc... " > That seems like an implementation detail for the network in question? something to make their qos filtering/marking/management simpler? -Chris _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Jan 31 03:46:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCB4u-0007e1-Hq; Wed, 31 Jan 2007 03:44:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCB4s-0007dk-5e for architecture-discuss@ietf.org; Wed, 31 Jan 2007 03:44:26 -0500 Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCB4q-0007ox-Ux for architecture-discuss@ietf.org; Wed, 31 Jan 2007 03:44:26 -0500 Received: from HeinerHummel@aol.com by imo-d20.mx.aol.com (mail_out_v38_r7.6.) id 9.d48.12d2e1d (29679); Wed, 31 Jan 2007 03:44:15 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Wed, 31 Jan 2007 03:44:12 EST Subject: Re: [arch-d] Use of IPv6 Addressing for QoS To: morrowc@ops-netman.net, william.d.ivancic@nasa.gov MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1234301244==" Errors-To: architecture-discuss-bounces@ietf.org --===============1234301244== Content-Type: multipart/alternative; boundary="-----------------------------1170233050" -------------------------------1170233050 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 It sounds like OSPF-MT (mt =3D multi topologies), doesn't it? =20 Heiner =20 In einer eMail vom 31.01.2007 06:14:19 Westeurop=E4ische Normalzeit schreibt= =20 morrowc@ops-netman.net: There are examples today in the v4 world of 'seperate networks' for =20 voice, video, data... how is that different than the proposed v6 =20 networks above? It seems perfectly fine (to me atleast) that people =20 might want to make a 'seperate network' for voice, video, private-ip-=20 data .... should we actively work to thwart that? would it do any =20 good? Perhaps they have more than a managable (in a v4 sense) number =20 of managed endpoints to deal with and v6 seems like it'd give them =20 management headroom? -------------------------------1170233050 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
It sounds like OSPF-MT (mt =3D multi topologies), doesn't it?
 
Heiner
 
In einer eMail vom 31.01.2007 06:14:19 Westeurop=E4ische Normalzeit sch= reibt=20 morrowc@ops-netman.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>There=20 are examples today in the v4 world of 'seperate networks' for 
vo= ice,=20 video, data... how is that different than the proposed v6 
networ= ks=20 above? It seems perfectly fine (to me atleast) that people 
might= =20 want to make a 'seperate network' for voice, video, private-ip-
data .= ...=20 should we actively work to thwart that? would it do any 
good?=20 Perhaps they have more than a managable (in a v4 sense) number 
o= f=20 managed endpoints to deal with and v6 seems like it'd give them =20
management headroom?

 
-------------------------------1170233050-- --===============1234301244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1234301244==-- From architecture-discuss-bounces@ietf.org Wed Jan 31 04:19:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBb9-0006o6-2U; Wed, 31 Jan 2007 04:17:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBb6-0006nq-Tl for architecture-discuss@ietf.org; Wed, 31 Jan 2007 04:17:44 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBb3-0000rJ-So for architecture-discuss@ietf.org; Wed, 31 Jan 2007 04:17:44 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0V9Het5118180 for ; Wed, 31 Jan 2007 09:17:40 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0V9He8g1347604 for ; Wed, 31 Jan 2007 09:17:40 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0V9HeuH016910 for ; Wed, 31 Jan 2007 09:17:40 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0V9Hdtc016905; Wed, 31 Jan 2007 09:17:40 GMT Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA225426; Wed, 31 Jan 2007 10:17:38 +0100 Message-ID: <45C05EB2.5030700@zurich.ibm.com> Date: Wed, 31 Jan 2007 10:17:38 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Chris Morrow Subject: Re: [arch-d] Use of IPv6 Addressing for QoS References: <6464C6A5-8103-458E-9F31-430AB6ECD64D@ops-netman.net> In-Reply-To: <6464C6A5-8103-458E-9F31-430AB6ECD64D@ops-netman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: architecture-discuss@ietf.org, "Ivancic, William D. \(GRC-RCN0\)" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 2007-01-31 06:09, Chris Morrow wrote: > > On Jan 30, 2007, at 12:18 PM, Ivancic, William D. (GRC-RCN0) wrote: ... >> The following are just some examples taken from some recent emails and >> other work: >> >> "One thought that came to mind was to distribute IPv6 addresses based on >> the class of/quality of service required. VOIP would get one range of >> addresses, non real-time data another, etc... " >> > > That seems like an implementation detail for the network in question? > something to make their qos filtering/marking/management simpler? And it makes no sense in a world where VoIP, video, and traditional services are mixed on the same subnets and the same devices, which may be mobile anyway. When I use my IP phone it has its own IP address; when I fire up my softphone, it takes over the same SIP and PSTN identity using a different IP address, sometimes on the same wire and sometimes on another continent. Trying to resolve the associated QoS challenges by playing with IP addresses isn't just a layer violation and extra semantic overloading of addresses: more important, it simply won't work. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss