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

[Gorry Fairhurst <[e-mail]>]

Architectural Implications of Link Indications
draft-iab-link-indications-01.txt

I like the idea behind this document, were you planning to develop it
further?

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.

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. 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.

I'm a little concerned with the way in which this topic is worded:

   However at this point, the algorithms for improving transport
   parameter estimates using link layer indications are not well
   understood.  For example, in transport parameter estimation, layering
   considerations may not exist to the same extent as in connection
   management.  For example, the Internet layer may receive a "Link
   Down" indication followed by a subsequent "Link Up" indication.  This
   information may useful for transport parameter estimation even if IP
   configuration does not change, since it may indicate that packet loss
   is not caused by congestion.

But also, link loss notification does not imply an absence of congestion...

IMHO, some possible other areas where guidance/caution/etc could be added
are:

* The implication of layer-2 relays that bridge between networks.

* The implications of network path asymmetry. Where the forward and return
paths use different links, the effect of link triggers could reduce
reliability of the overall network path. 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.

----

   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.

   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?

   the Transport layer
   may wish to control the maximum number of times that a link layer
   frame may be retransmitted, so that the link layer does not continue
   to retransmit after a Transport layer timeout.

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)

(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?

-----

In 2.7...

   so that ICMP "source quench" indications are
   not needed, and in fact the sending of additional "source quench"
   packets during periods of congestion may be detrimental.

True, but rather understated, perhaps???

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.

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...

------

[c]   Security.  Proposals need to describe how security issues can be
      addressed.  Where link indications are transported over the
      Internet,  an attack can be launched without requiring access to
      the link.

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?) 

Both of these are much more difficult when transporting the triggers over a
L3 infrastructure.


Hope that this makes some kind of sense,

Best wishes,

Gorry Fairhurst




_______________________________________________
pilc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/