From ternli-bounces@ietf.org Thu Feb 08 12:12:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFCoT-0004nh-3z; Thu, 08 Feb 2007 12:12:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAV9-0006vm-NW for ternli@ietf.org; Thu, 08 Feb 2007 09:43:55 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFAV3-0002x3-Ti for ternli@ietf.org; Thu, 08 Feb 2007 09:43:55 -0500 Received: from c-24-16-66-58.hsd1.mn.comcast.net ([24.16.66.58] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1HFAV3-000Oc5-Fv for ternli@ietf.org; Thu, 08 Feb 2007 09:43:49 -0500 Received: by internaut.com (Postfix, from userid 1000) id 7B78921E99; Thu, 8 Feb 2007 06:43:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 69EC0D90D for ; Thu, 8 Feb 2007 06:43:51 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.66.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 8 Feb 2007 06:43:51 -0800 (PST) From: Bernard Aboba To: ternli@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Thu, 08 Feb 2007 12:11:59 -0500 Subject: [TERNLI] Request for review X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org The IAB is considering publication of "Architectural Implications of Link Indications", and would interested in feedback from the transport community. The latest version of the document can be found here prior to appearance on the I-D archive: http://www.drizzle.com/~aboba/IAB/draft-iab-link-indications-07.txt Feedback can be sent to iab@ietf.org. From ternli-bounces@ietf.org Thu Feb 15 05:17:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHdgN-0005oR-Pf; Thu, 15 Feb 2007 05:17:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHdgL-0005nl-TV; Thu, 15 Feb 2007 05:17:41 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHdgK-0001lu-Bz; Thu, 15 Feb 2007 05:17:41 -0500 Received: from [139.133.207.152] (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l1FAHGwG022020; Thu, 15 Feb 2007 10:17:16 GMT Message-ID: <45D433CF.6080501@erg.abdn.ac.uk> Date: Thu, 15 Feb 2007 10:19:59 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Subject: Re: [TERNLI] Request for review -NiTS rev -07 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: ternli@ietf.org, iab@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org Here are some NiTs to be considered by the authors in their next revison, Best wishes, Gorry Bernard Aboba wrote: > The IAB is considering publication of "Architectural Implications of Link > Indications", and would interested in feedback from the transport > community. > > The latest version of the document can be found here prior to appearance > on the I-D archive: > http://www.drizzle.com/~aboba/IAB/draft-iab-link-indications-07.txt > > Feedback can be sent to iab@ietf.org. > > NITS --- 1.1 Routable Address /In this specification, the term "routable address" refers to any IPv4 address other than an IPv4 Link-Local address./ - Why so IPv4 centric? - I don't see why the discussion in the document does not also relate to IPv6 addresses, and if we can we should make general guidance for IP, rather than version-specific guidance, please provide IPv6 reference. - Many of the later examples are taken from IPv4, which is fine, but it would be good to see up-front that these issues also apply to IPv6 (which they seem to). --- 1.1 /characteristics which/ should be: /characteristics that/ ^^^^ ---- /Link indication/ should be: /Link Indication/ ^ --- /Operable address/ should be: /Operable Address/ ^ --- /Routable address/ should be: /Routable Address/ ^ --- /In this specification,/ ^^^^^^^^^^^^^ - In this document? - this is not a protocol spec. --- /sent out an interface/ ^^^^^^ - The English here does not read well for a british reader, could this be "by an interface"? /sent on an outgoing interface/ ^^^^^^^^^^^^^^^ --- Section 1.4.1 /indications may not result in a/ - can be misread by some English-speaking readers as MUST NOT... I suggest: /indications do not necessarily result in a/ ^^^^^^^^^^^^^^^^ --- /Link indications such "Link Up"/"Link Down" or changes in rate/ - insert "as" after "such". --- Section 1.4.2 Transport Layer /bottleneck bandwidth is already/ - It's not clear which bottleneck here. should be: /bandwidth of the bottleneck on the end-to-end path is already/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ --- 1.4.2. Transport Layer - I prefer adding the word "received" /The Transport layer processes link indications differently for/ Could it be: /The Transport layer processes received link indications differently for/ ^^^^^^^^ --- Section 2.1 /avoid use of link models/ - insert 'the' /avoid the use of link models/ ^^^ --- Section 2.3.2, /The problem was caused by an invalid / - This paragraph break seems to be wrong - perhaps this is part of the previous para? --- Section 2.6 / Duplicate Address Detection (DAD)./ - cite? [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006. --- Section 2.7 / transport parameters for the original interface (MTU, congestion state)/ - the MSS (derived from link MTU, or PMTU)... --- A.1.2 Smart Link Layer Proposals Consider adding?: [RFC3366] provides advice to the designers of digital communication equipment and link-layer protocols employing link-layer Automatic Repeat reQuest (ARQ) techniques for IP. It discusses the use of ARQ, timers, persistency in retransmission and the challenges that arise from sharing links between multiple flows and in differentiation transport flow requirements. From ternli-bounces@ietf.org Thu Feb 15 05:17:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHdgc-0005xt-0g; Thu, 15 Feb 2007 05:17:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHdga-0005wu-Td; Thu, 15 Feb 2007 05:17:56 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHdgV-0001qS-I4; Thu, 15 Feb 2007 05:17:56 -0500 Received: from [139.133.207.152] (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l1FAHEk8022019; Thu, 15 Feb 2007 10:17:14 GMT Message-ID: <45D433CD.2050200@erg.abdn.ac.uk> Date: Thu, 15 Feb 2007 10:19:57 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ternli@ietf.org, iab@ietf.org, Gorry Fairhurst , Bernard Aboba Subject: Re: [TERNLI] Request for review - Questions from rev -07? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org I some questions and comments that I'd like to understand the answers to, please see below. Best wishes, Gorry --- COMMENTS on rev -07 ---- 1) Definitions: Strong End System Model /does not correspond to the physical interface/ - Are these addresses at the link or network layer? - I can't quite tell from this what is meant, could it please be rephrased ro be more clear? Definitions: Weak End System Model - Is this then, the "normal" IP host behaviour? ---- 2) Section 1.4.2 Transport Layer /For example, the Transport layer may utilize the receipt of a "Link Down" indication followed by a subsequent "Link Up" indication to infer the possibility of non-congestive packet loss during the period between the indications, even if the IP configuration does not change as a result, so that no Internet layer indication would be sent./ - OK, but this example assumes that the transport layer knows the indication came from a link forming a part of the path, for example it was the directly connected link to the sender or receiver. Could this be explained in the text perhaps? ---- 3) Section 1.4.2 Transport Layer /Since hosts implementing "Path MTU Discovery" [RFC1191] use Destination Unreachable code 4, they do not treat this as a hard error condition./ - I suggest you also cite the recommended successor, "draft-ietf-pmtud-method-11", which will be RFC before this I-D is published. This does NOT rely on vulnerable network-layer indications using ICMP to perform path MTU discovery. ---- 4a) Figure 1: /MTU/ - Should this transport layer segment size, MSS? - IMHO, this little difference is important, since it reflects the indirect communication between layers that is spoken about later (i.e. MSS is set as a result of local MTU and discovered PMTU). - Should this therefore perhaps also mention cached PMTU value for the path as a network property? ---- 4b) Section 2.3.2 /Where a proposal involves recovery at the transport layer, the recovered transport parameters (such as the MTU, RTT, RTO, congestion window, etc.) should be demonstrated to remain valid. / - see above, MTU is not a transport parameter, "MSS". - As previous you could also add the Internet layer PMTU as a parameter that could be re-verfied after a potential path change. --- 5) Section 2.9 /As noted earlier, the transport layer may take the state of the local routing table into account in improving the quality of transport parameter estimates. For example, by utilizing the local routing table, the Transport layer can determine that segment loss was due to loss of a route, not congestion. / - This causes me to worry. - At the moment it does not mention the corresponding important issue of congestion control - absence of positive feedback that the path is sending data end-to-end must be heeded, although of course, it seems plausible to consider such a signal as a "lack" of congestion information, and therefore to trigger congestion control probing. ---- 6) Section 2.9 /[b] Mitigation of security vulnerabilities. Transported link indications that modify the local routing table represent routing protocols, and unless security is provided they will introduce the vulnerabilities associated with unsecured routing protocols. For example, unless schemes such as SEND [RFC3971] are used, a host receiving a link indication from a router will not be able to authenticate the indication. Where indications can be transported over the Internet, this allows an attack to be launched without requiring access to the link./ - This example mixes up the Internet Layer (SEND, routing, etc). - Is there a good transport example? ---- 7) Section 2.9 /[d] Mapping of Identifiers. When link indications are transported, it is generally for the purposes of saying something about Internet, Transport or Application layer operations at a remote element. These layers use different identifiers, and so it is necessary to match the link indication with relevant higher layer state. Therefore proposals need to demonstrate how the link indication can be mapped to the right higher layer state. For example, if a presence server is receiving remote indications of "Link Up"/"Link Down" status for a particular MAC address, the presence server will need to associate that MAC address with the identity of the user (pres:user@example.com) to whom that link status change is relevant./ - All seems true... but presence isn't a classic transport-layer example, please find an example from SCTP, TCP, UDP, DCCP, etc... - And at the transport-layer entity would need to associate each indication with a corresponding specific (or set of) transport sessions (port,address) combination, that are impacted by the change... which is even more tricky ;-) --- 8) Section 2.9 [d] - This should, IMHO, also mention that transport sessions are not necessarily visible to link entities generating transported link indications due to various things, (or mention in section 4.3?) e.g.: * Load-sharing between multiple links * VPN and IPsec * Tunnel overlays, including mobile IP (that do not prevent access to higher layer headers, but would require parsing of multiple protocol headers). --- 9) / This way transport parameters are not adjusted as though congestion were detected when loss is occurring due to other factors such as radio propagation effects or loss of a route (such as can occur on receipt of a "Link Down" indication)./ - Can we be more careful here in what we are asserting? - This current statement seems dangerous... A given basis for congestion control is that the sending transport has consumed capacity on the path it will use and that it has reasonable evidence that the path is capable of supporting the rate. A loss of data (even due to non-congestion corruption) needs to be accompanied by a positive confirmation that other traffic was received, and does not necessarily tell the transport entity that the lost traffic WOULD have got through had it been sent at another moment (i.e. there could be another bottleneck). Done incorrectly, this will negatively impact other flows that share capacity. - In short, any new work needs to assess the congestion control issues that arise when the transport flow shares the path which it is using with other transport flows (these may, or may not, use the link that is providing indications)? =========================================== From ternli-bounces@ietf.org Thu Feb 15 17:52:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpSs-00059x-Cr; Thu, 15 Feb 2007 17:52:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHmK4-0004rg-Tu; Thu, 15 Feb 2007 14:31:16 -0500 Received: from bay0-omc2-s41.bay0.hotmail.com ([65.54.246.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHmJz-0001hw-Gy; Thu, 15 Feb 2007 14:31:16 -0500 Received: from hotmail.com ([207.46.8.96]) by bay0-omc2-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 15 Feb 2007 11:31:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Feb 2007 11:31:10 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 15 Feb 2007 19:31:06 GMT X-Originating-IP: [71.217.44.143] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <45D433CF.6080501@erg.abdn.ac.uk> From: "Bernard Aboba" To: gorry@erg.abdn.ac.uk, aboba@internaut.com Bcc: Subject: Re: [TERNLI] Request for review -NiTS rev -07 Date: Thu, 15 Feb 2007 11:31:06 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Feb 2007 19:31:10.0705 (UTC) FILETIME=[D8E16610:01C75137] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 X-Mailman-Approved-At: Thu, 15 Feb 2007 17:52:32 -0500 Cc: ternli@ietf.org, iab@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org Thank you! Revisions to the document (in progress) will be available here: http://www.drizzle.com/~aboba/IAB/draft-iab-link-indications-08.txt >From: Gorry Fairhurst >Reply-To: gorry@erg.abdn.ac.uk >To: Bernard Aboba >CC: Gorry Fairhurst , ternli@ietf.org, iab@ietf.org >Subject: Re: [TERNLI] Request for review -NiTS rev -07 >Date: Thu, 15 Feb 2007 10:19:59 +0000 > > >Here are some NiTs to be considered by the authors in their next revison, > >Best wishes, > >Gorry > > >Bernard Aboba wrote: > >>The IAB is considering publication of "Architectural Implications of Link >>Indications", and would interested in feedback from the transport >>community. >> >>The latest version of the document can be found here prior to appearance >>on the I-D archive: >>http://www.drizzle.com/~aboba/IAB/draft-iab-link-indications-07.txt >> >>Feedback can be sent to iab@ietf.org. >> >> > > >NITS > >--- >1.1 Routable Address > /In this specification, the term "routable address" refers to any > IPv4 address other than an IPv4 Link-Local address./ >- Why so IPv4 centric? >- I don't see why the discussion in the document does not also relate to >IPv6 addresses, and if we can we should make general guidance for IP, >rather than version-specific guidance, please provide IPv6 reference. >- Many of the later examples are taken from IPv4, which is fine, but it >would be good to see up-front that these issues also apply to IPv6 (which >they seem to). >--- >1.1 >/characteristics which/ >should be: >/characteristics that/ > ^^^^ >---- >/Link indication/ >should be: >/Link Indication/ > ^ >--- >/Operable address/ >should be: >/Operable Address/ > ^ >--- >/Routable address/ >should be: >/Routable Address/ > ^ >--- >/In this specification,/ > ^^^^^^^^^^^^^ >- In this document? - this is not a protocol spec. >--- >/sent out an interface/ > ^^^^^^ >- The English here does not read well for a british reader, could this be >"by an interface"? >/sent on an outgoing interface/ > ^^^^^^^^^^^^^^^ >--- >Section 1.4.1 >/indications may not result in a/ >- can be misread by some English-speaking readers as MUST NOT... >I suggest: >/indications do not necessarily result in a/ > ^^^^^^^^^^^^^^^^ >--- > /Link indications such > "Link Up"/"Link Down" or changes in rate/ >- insert "as" after "such". >--- >Section 1.4.2 Transport Layer >/bottleneck bandwidth is already/ >- It's not clear which bottleneck here. >should be: >/bandwidth of the bottleneck on the end-to-end path is already/ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >--- >1.4.2. Transport Layer >- I prefer adding the word "received" >/The Transport layer processes link indications differently for/ >Could it be: >/The Transport layer processes received link indications differently for/ > ^^^^^^^^ >--- >Section 2.1 >/avoid use of link models/ >- insert 'the' >/avoid the use of link models/ > ^^^ >--- >Section 2.3.2, >/The problem was caused by an invalid / >- This paragraph break seems to be wrong - perhaps this is part of the >previous para? >--- >Section 2.6 >/ Duplicate Address Detection (DAD)./ >- cite? >[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for >IPv6", RFC 4429, April 2006. >--- >Section 2.7 >/ transport parameters for the original interface (MTU, congestion state)/ >- the MSS (derived from link MTU, or PMTU)... >--- >A.1.2 Smart Link Layer Proposals > >Consider adding?: > > [RFC3366] provides advice to the designers of digital > communication equipment and link-layer protocols employing link-layer > Automatic Repeat reQuest (ARQ) techniques for IP. It discusses the use > of ARQ, timers, persistency in retransmission and the challenges that > arise from sharing links between multiple flows and in differentiation > transport flow requirements. > >