On Wed, Feb 25, 2015 at 12:36 PM, Curtis Villamizar
<[email protected]> wrote:
>
> In message <[email protected]>
> Juliusz Chroboczek writes:
>>
>> > Thought: In general, my feeling is that L2 link status is widely relied
>> > upon in commercial product/dpeloyments. If homenet feels it can not rely
>> > on it due to the non-commercial nature of its development platforms,
>> > thats an interesting aspect, especially because it could impact an IETF
>> > standard that we'd like to see commercially implemented and then the
>> > constraints could be different...
>>
>> Are you referring to the routing protocol comparison, or to something else?
>>
>> I have the impression that Babel and IS-IS behave essentially the same
>> wrt. L2 status -- they both converge fast enough after link status has
>> been established, and they essentially provide the same facilities for
>> application-layer link sensing (IMHO Babel's Hello/IHU subprotocol is
>> slightly more flexible, but that's probably not a big deal).
>>
>> As to wireless links -- as far as I'm aware, making efficient use of
>> wireless L2 information in a routing protocol is an open research problem.
>
> Other than signal strength and collision rate, what L2 information is
> available?  Per MAC information would be nice for the AP side or any
> node in mesh or adhoc mode but that isn't collected anywhere AFAIK.
>
>> -- Juliusz
>>
>> _______________________________________________
>> homenet mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/homenet
>
>
> ISPs mostly use Ethernet as point-to-point (PTP) links.  Including
> using 100GbE as PTP.  No switches.  L2 Link down is one fast indicator
> of link down.  But for Ethernet over transport gear (ie: OTN) BFD is
> almost always used.  For short distances L2 over extended reach optics
> can be used, including colored optics and WDM.  This is also PTP and
> in this case BFD should not be needed.  To the extent that routers use
> SONET or OTN interfaces, these have fast L2 link down indication and
> are integrated with L3 link down detection.  In all of these detection
> is on the order of 10 msec (geographic distance dependent), failover
> using FRR is under 50 msec, and IGP convergence is well under a second
> (typical 100-200 msec today AFAIK).  L3 hellos are way too slow.
>
> BFD is not heavy weight.  L3 hellos (OSPF, ISIS) can be set down to 1s
> with detection in 3s (too slow).
>
> BFD, Hellos, or any form of probe traffic over wireless has the speed
> of detection vs overhead issue.  At nominal 10 Mb/s (low end today for
> wireless) a small probe would take about 0.1 msec (for example, 125
> bytes including all overhead is about 1000 bits).  Not bad if running
> 100 probes/sec (30 msec detection) unless there are a very large
> number of stations using the AP and doing the same thing.  In that

You are thinking about it wrong. Wireless-g is only capable of roughly
1300 TXOPs total per second. Bandwidth has NOTHING to do with it.

I don't have the figure in my head for n or ac, but it is not a lot, and
in the presence of g, falls back to the above figure.

losing 10% of the bandwidth - per station - to run BFD is not an option.

> case 10 probes per second might be better.  A very high collision rate

Still too much. Next question?

> (typically not due to probes, but to real traffic) might result in a
> link down indication.  If that is the case, then moving to another AP
> would be a good thing.
>
> Flapping needs to be avoided if an alternate is available (ie: with
> 20% loss, in .2*.2*.2 = .008 = 0.8% of intervale a down indication
> would occur).  If any packet received would bring it back up, then at
> 100 probes / sec, a change in IGP link state could occur about once a
> second on average.  Remembering a link down and holding a down state
> for a (longish) while would be a good thing.  If there is no alternate
> route, not probing at all and/or holding an up state would be good.
> OTOH- 20% loss borders on completely unusable.
>
> Curtis
>
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to