[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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