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/