Re: [Kbfd-devel] [kbfd] DiffServ Code Point to eliminate packet loss or congestion
Status: Alpha
Brought to you by:
thehajime
|
From: Peter S. <pes...@gm...> - 2008-06-09 07:06:54
|
On Sat, Jun 7, 2008 at 2:50 PM, Hajime Tazaki <ta...@sf...> wrote: > > Prioritizing packet with DSCP is good idea, but I think that > this couldn't be absolute solution, though.. > But some situation is helped by this trick. > > BTW, I think that BFD needs some "flapping protection > method" in core specification. The problem you explained > might be happened in real world. I'm not sure flapping protection is within the scope of BFD, if by flapping we mean real interface failure/recovery. BFD should report link state changes according to its timeout settings, and should not obscure them even if it considers them to be flapping. OTOH if we try to deal with the problem I described above (that is, a "virtual" flapping due to delayed/lost BFD control packets), there's not much to do in BFD level except using enlarged timer intervals -- or, some kind of priority given to BFD packets, e.g. DSCP. Whether BFD packets need this special treatment is to be judged by the user of the BFD implementation, not by the implementation itself. > The prioritizing technique doesn't work all situation, and > if one box could prioritize the BFD processing with OS > support or hardware assist, the intermediate node would not > treat such way. The internet is always so. You are right in general, but if someone manages a routing domain on his own, it is possible to set up a QoS-aware packet scheduler in every router (at least on the links monitored by BFD). > So the best way for us is only DSCP, I think. Indeed, I think it would improve the quality of failure detection by enabling the use of smaller timeout intervals without being prone to packet loss or delay. We plan to test this solution within a couple of weeks, and I will assemble a patch if we found it useful in practice. Regards, Peter |