Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events?

From: "Bound, Jim" <[email-masked]>
Date: Sun, 29 May 2005 18:59:22 -0400

> I think it would be good if the definitions would clarify 
> that even if 
> the link layer on the host sees 100% packet loss for a short 
> while, it 
> doesn't necessarily imply that a link down event should be generated.
> (It presumably shouldn't be generated until the link layer 
> abandons the 
> L2 association/connection/whatever.)

I agree in theory.  In practice I may implement to bring the link-down,
if it is not my only link-access, as far as IP stack is concerned.
Reason is node/device may have multiple link-access mediums and this one
is not performing.  I think we all understand where I am going. My
reason for stating the obvious is does this context affect what we do
within DNA?

/jim

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 31 May 2005 10:16:45 -0700

Bound, Jim wrote:

> I agree in theory.  In practice I may implement to bring the link-down, if
> it is not my only link-access, as far as IP stack is concerned.  Reason is
> node/device may have multiple link-access mediums and this one is not
> performing.  I think we all understand where I am going. My reason for
> stating the obvious is does this context affect what we do within DNA?

I think what we are doing is coming up with definitions of the concepts 
of link up/down that are useful for DNA, and does not prevent things 
like "link quality" to be taken into account, especially for hosts with 
multiple interfaces.

It is probably the case that a host with multiple interfaces will work 
best if it takes into account a number of factors (from packet loss 
rates and bandwidth, to monetary cost for using a NIC and application 
requirements) when choosing which NIC to use (and for what application 
traffic). I also suspect that such strategies doesn't require that DNA 
stop considering an interface. For instance, if the stack+applications 
decide to use the GPRS interface for VoIP traffic, it is probably still 
useful to have DNA monitor the 802.11 interface to detect when the host 
gets back in range of the AP.

But that clearly shouldn't prevent implementations that just use simpler 
strategies such as "haven't heard from the AP in 30 seconds" to just 
abandon the use of the 802.11 interface.

I don't see the definitions that Bernard updates as restricting the 
implementation in any way; could be as simple or as complicated as it 
wants when handling multiple NICs.
If you think they are restricting the implementations then we should 
clarify the definitions further.

    Erik

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 31 May 2005 11:22:55 -0700 (PDT)

> like "link quality" to be taken into account, especially for hosts with

"Link-aware" routing metrics date back to the original ARPAnet packet
radio experiments, and more recent work has established the importance of
taking link quality into account.  For example, see:

http://research.microsoft.com/mesh/papers/metrics.pdf
http://pdos.csail.mit.edu/~rtm/papers/etx.pdf
http://pdos.csail.mit.edu/papers/grid:losstr02/paper.pdf
http://www.ee.ucla.edu/~kulkarni/papers/Routing.pdf

> traffic).

All this can be taken into account by adjusting routing metrics.  In
particular, routing metrics can automatically make a decision about
whether to route packets over another interface once the link quality
begins to deteriorate.

> I also suspect that such strategies doesn't require that DNA

Routing metrics only become relevant when an interface is "up" and
configured for communicating IP packets.  DNA helps speed up that process,
but it isn't involved in making the decision whether to enable an
interface or not.  Similarly, bringing an interface down is a separate
decision from deciding whether to use it to route a particular packet.

However, I do think that decisions on enabling/disabling interfaces do
need to take routing metrics into account, or else inconsistencies can
result.  For example, if you bring an interface up that has a higher
routing metric than another interface, it won't be used except perhaps if
it can reach prefixes that the other interface can't.  If "idle timeout"
is in effect, then the unused interface will only be brought down again.

Similarly, if "dial on demand" is in effect, then if you bring an
interface down that had a lower routing metric than an existing interface,
then it will only be brought up again.

So my take is that routing metrics are actually fairly fundamental to
multi-homing behavior.  For example, MIT LCS has an interesting paper
on rate negotiation algorithms:
http://pdos.csail.mit.edu/~rtm/srcrr-draft.pdf

> abandon the use of the 802.11 interface.

That would be a particularly poor algorithm to use since the detection
time is larger than RTOmin.  In general, a NIC should probably start
scanning after only 3 retransmissions (unlikely to occur merely due to
congestion) and should consider moving to another AP before RTOmin.  For
example, even poor rate negotiation implementations typically can move
from the highest bit rate to the lowest (typically 1 Mbps) in 200 ms.

> wants when handling multiple NICs.

I don't see them restricting an intelligent implementation either.  But
I've seen enough bad ones that I'd prefer to rule out the most egregious
behavior.