Re: [DNA] Review of draft-ietf-dna-link-information-03.txt

[James Kempf <kempf@docomolabs-usa.com>]

I believe the DNAv6 protocol spec says that RS probes occur upon a hint from 
L2 that the link has changed. The nature of the hint is left as an exercise 
to the implementor, and may, in fact, be quite different depending on the 
nature of the L2 protocol. Is that acceptable?

Regarding jitter, I don't recall whether that is dealt with on the host side 
in DNAv6, but there is an extensive discussion of a token bucket algorithm 
on the router to protect the routers and other hosts on the link against 
flooding. IHO, regardless of what the spec says about the host side, 
someobody could always hack the driver to flood the link. The DT was 
primarily concerned with protecting against such attacks, but I suppose it 
might be appropriate to include some text in the spec to protect against 
malfunctions as well.

            jak

----- Original Message ----- 
From: "Bernard Aboba" <bernard_aboba@hotmail.com>
To: <jari.arkko@kolumbus.fi>
Cc: <dna@eng.monash.edu.au>
Sent: Tuesday, May 23, 2006 10:52 AM
Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt


> >Anyway, I have a question for you Bernard: draft-iab-link-indications
>>talks about the importance of damping and hysterisis -- has that
>>been sufficiently addressed in the wireless parts of the
>>dna-link-information document?
>
> Damping & hystersis need to be addressed in the DNA specifications 
> themselves, so that DNA can be immune to driver malfunctions.  As an 
> example, RFC 4436 rate limits DNAv4 exchanges, so that a jittering driver 
> would not cause a flood of DNAv4 probes.
>
> I do think this document creates a problem by mandating that a "link down" 
> event be sent on each handoff.  It is possible for a handoff to occur with 
> minimal connectivity loss, so that the link was never "down", at least not 
> long enough for an application to care about it.  Requiring "link down" 
> events will cause harm in situations where the TCP stack or applications 
> tear down connections on receipt of a "link down".   Because of the 
> downside to sending a "link down" event, these events are often damped, 
> and if a "link up" occurs prior to expiration of the damping timer, then a 
> "link down" event may not be sent.
>
>
>