Re: I-D ACTION:draft-iab-link-indications-01.txt

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
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/