Re: [pilc] I-D ACTION:draft-iab-link-indications-01.txt
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 17 January 2005 19:38 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06553 for <pilc-archive@lists.ietf.org>; Mon, 17 Jan 2005 14:38:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcgA-0004iA-AE; Mon, 17 Jan 2005 14:36:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcbT-0004PL-Pl for pilc@megatron.ietf.org; Mon, 17 Jan 2005 14:31:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06109 for <pilc@ietf.org>; Mon, 17 Jan 2005 14:31:51 -0500 (EST)
Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqcqV-0004jl-JW for pilc@ietf.org; Mon, 17 Jan 2005 14:47:30 -0500
Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j0HJUnlt018848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jan 2005 19:30:50 GMT
Message-ID: <41EC126A.2040708@erg.abdn.ac.uk>
Date: Mon, 17 Jan 2005 19:30:50 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: Univesrity of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
Subject: Re: [pilc] I-D ACTION:draft-iab-link-indications-01.txt
References: <BAY24-F208E2A2D6B3A6438FE21A2938E0@phx.gbl>
In-Reply-To: <BAY24-F208E2A2D6B3A6438FE21A2938E0@phx.gbl>
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-ERG-MailScanner-To: aboba@internaut.com, bernard_aboba@hotmail.com, falk@isi.edu, pilc@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
Content-Transfer-Encoding: 7bit
Cc: falk@isi.edu, aboba@internaut.com, pilc@ietf.org
X-BeenThere: pilc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Performance Implications of Link Characteristics IETF Working Group <pilc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pilc>, <mailto:pilc-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pilc@ietf.org>
List-Help: <mailto:pilc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pilc>, <mailto:pilc-request@ietf.org?subject=subscribe>
Sender: pilc-bounces@ietf.org
Errors-To: pilc-bounces@ietf.org
Content-Transfer-Encoding: 7bit
Bernard Aboba wrote: >> I like the idea behind this document, were you planning to develop it >> further? > > > It is an IAB document, so yes, we are planning on continuing to develop it. > >> Although many issues seem to have been explored for the network layer, >> the >> Transport layer considerations seem much less developed. I think it >> could be >> better to have more on the implications of providing this information >> to the >> transport-layer within a general Internet context. > > > Yes, I think that is fair. Recommendations welcome. > >> When I was reading it, I was trying to understand whether the prime >> motivation was to handle end hosts that were directly connected to the >> link >> reporting its state, or whether the document was also addressing the case >> with other L2 or L3 elements (routers, bridges) between the link and >> the end >> host. > > > The unifying concept for both direct connection and distant links is > that they both generate "path change" indications. So the issue is > really how the Transport layer handles those indications. > > Path changes can be determined both directly (e.g. change in incoming or > outgoing interface, change in incoming TTL) and from external sources > (receipt of MIPv6 BU, routing protocol update). > > If one focuses on path change indications, it is not clear to me that > the source of the indication should matter. > I seem to have missed something: if the signal is not from a local interface, I don't yet understand the mechanism that tells the transport layer that a specific "indication" that was produced somewhere in the network is authorative to a specific transport layer entity (TCP session, DCCP Session, or whatever). If you don't know that the reporting source is *actually* forwarding most/all of the packets for this session, and you don't know whether there are alternate paths also in use, then should the transport entity take any notice? >> I recall this was an area that was debated within the BOFs on >> link-triggers and trigtran - the issues being much more acute when not >> considering directly connected hosts. > > > Part of the reason for writing this document is to summarize some of the > conclusions of that debate - and challenge others (such as the relevance > of the distinction between local and remote indications). > I don't understand this. >> But also, link loss notification does not imply an absence of >> congestion... > > > Sure. The document describes the link indications that *may* be > relevant, but it doesn't say much about what should be done with them. > One way to improve the document in that area might be to include more > discussion of transport research in the literature review. References > welcome. > >> * The implication of layer-2 relays that bridge between networks. > > > As I understand it, this concern arises from the lack of visibility that > the host has in this situation. However, I'm not entirely clear that a > "path change indication" can't be generated here as well. For example, > there are hosts that do "dead gateway detection" can can switch their > default route if a gateway becomes unreachable. Similarly, when the > gateway comes up, reachability might be recovered. But here again, if this is an end host's nearest neighbour, the end host knows that this is on-the-path. Once you move one stage further away, then does the end host have this knowledge? > >> * I suggest that link integrity >> checks rely upon bi-directional link connectivity to verify the remote >> reception of frames, whereas Transport protocols only require the >> end-to-end >> communication path exists. > > > Are you saying that the Transport layer needs an indication from the > Internet layer that isn't described in the document? I'd had assumed > that the "IP address configured" indication was dependent on > demonstration of bi-directional reachability, in order to address > potential link layer asymmetries. > I wondered if an end host could react to indications that arise due to a lack of a specific link's bi-directional link availability which could reduce the robustness of fate-sharing? At the moment, a transport layer entity does not care whether the under-lying links have bi-directional or uni-directional connectivity. What they care about is whether there is reachability between the end hosts. (Bi-directional connectivity may be needed by network layer routing protocols - but static routes, UDLR, etc, don't need this). I wanted to know if this could change this? >> In addition to Internet layer indications propagated to the >> Application layer (such as IP address configuration and changes), the >> Transport layer provides its own indications to the Application >> layer, such as connection teardown. >> >> The transport layer also has its own mechanisms for loss detection, >> congestion detection, (reordering perhaps?) these work on the >> timescale of >> the total PRTT, rather than a specific link RTT. > > > Are you suggesting that these be included in the transport indications > passed to the applications layer? > I'm suggesting that link state can change rapidly, whereas transport entities tend (at least at the moment) to react much more slowly, allowing time for the under-lying links to recover/retransmit/multiplex traffic, etc. It may be wiser for a transport protocol to ignore "flapping state", at least until such time that it is sure that there is no alternate path, retransmission, etc. on the way. >> The Transport layer may also >> provide indications to the link layer. For example, to prevent >> excessive retransmissions within the link layer, >> >> Does this assume the link is directly connected to an end host, or are >> you >> thinking about an end host setting policy in down/up stream routers too? > > > In this particular case, we were talking only about the local host. As > assumed in the document propagation of link indications beyond the local > link occurs only due to changes in routing metrics. One might argue that > PRTT is relevant to calculation of a metric such as ETX if the > combination of the link RTT and the max number of retransmissions can > exceed the path RTT, because at that point we will have both PHY layer > retransmission and Transport layer retransmission (a bad thing). > Not sure that I would go as far as "bad", but this is suboptimal (as in RFC3366). >> Could be so, but for TCP I have two queries: >> >> (i) The link persistency (i.e. Maximum period for retransmission of a >> packet) is of the order of the TCP PRTT, that is of the order of seconds? >> (RFC3366 has some discussion on this) > > > In experiments I have seen 802.11 implementations that continue to > retransmit for 30 seconds until determining that the AP is no longer > there and scanning for a new point of attachment. This seems like a bad > thing, even if the time between retransmissions were considerably less > than RTOmin. yes - seems like not a wise thing to do, and that's why it is not recommended. > >> (ii) Is saving this capacity a significant factor? >> >> In 802.11, this can >> be achieved by adjusting the MIB variables dot11ShortRetryLimit >> (default: 7) and dot11LongRetryLimit (default: 4), which control the >> maximum number of retries for frames shorter and longer in length >> than dot11RTSThreshold, respectively. >> >> I'm not familiar with this - but I wonder if these MIBs allow the >> sender to >> specify a filter record to say which specific transport layer packets >> are to >> effected - or does the MIB set global link behaviour? - If it is the >> latter, >> then how do you reconcile different transport sessions (possibly also >> using >> different protocols) requesting different behaviour? > > > It's global behavior, and so it can't really be used at that granular a > level. But you can try to make sure that an 802.11 station isn't still > retransmitting after RTOmin, for example. > If this is global IP forwarding behaviour, I worry then that you think a transport entity should change this. > >> Among other serious considerations against this approach are: >> >> * How to determine the timing when such messages were to be generated >> without knowledge of the PRTT of the end hosts being affected. >> * How to interpret these on paths of varying capacity. >> * Source Quench would also introduce a DoS opportunity, >> * It would probably have fallen into the same problems as PMTUD did when >> encountering tunnels (i.e. What should tunnels do with such messages >> experienced along the tunnel path?). >> >> I suspect the same would be true of network-level transport of link >> triggers. > > > Yes, I think so. > >> In general, link loss indications are hard to interpret when a link forms >> only a part of an Internet path. Knowing there was packet loss on a link >> doesn't provide a useful indication to the transport layer unless the >> loss >> events can be traced to a specific transport session. Even then, the >> congestion state of all links/routers has to be taken when the path could >> comprise other links apart from that at the point of loss... > > > I'd agree. On the other hand, if the routing metric is link-aware, then > high loss will increase the metric and potentially cause a path change, > which might be detectable at the end host, either implicitly (RTT goes > down) or explicitly (TTL changes). > So..... what does the Transport protocol entity do with this "knowledge"? >> I suggest that trusted use of such triggers implies: >> >> * An (security) association with the element receiving the trigger >> transmissions and the source of these transmissions (to verify the >> identity >> of the source - hmmm even if I know the source is actually within ISP-A's >> domain, would I trust it from ISP-B?) >> *AND* >> * Verification that the source is actually on the current path that is >> being >> used between the sender and receiver (not sure how you do this in the >> general case?) > > > Remember, routing metrics can be link aware -- but the above > considerations are generally *not* met by routing protocols, which > provide hop-by-hop security. One might argue that lack of end-to-end > routing security is already a problem (e.g. with BGP). But I'm not > clear that we need to solve that issue in order to use existing routing > protocols with new metrics such as ETX. > > > _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/
- [pilc] I-D ACTION:draft-iab-link-indications-01.t… Aaron Falk
- Re: [pilc] I-D ACTION:draft-iab-link-indications-… Gorry Fairhurst
- Re: [pilc] I-D ACTION:draft-iab-link-indications-… Gorry Fairhurst