Re: [DNA] draft-ietf-dna-cpl-02.txt

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Erik

> (But blowing away all the TCP connections
> just because the 802.11 AP becomes unreachable for a few seconds might
> be too aggressive.)

Nobody seems to be in favor of immediately blowing TCP away.

> FWIW section 4.6 in draft-ietf-dna-cpl does specify what is required to
> be discarded.
> But it is silent about any implications on ULP traffic.
>  From the perspective of the document, it might make sense to add the
> same language as we have for invalid addresses in RFC 2462 (which is
> that the host should not send any packets using such addresses as source).
>
> I agree that the ULP implications have be argued either way, and the
> optimal behavior is application dependent.

agree. Different applicaions with different requirements, such as
'file transfer' and 'VoIP', may need to behave differently.

> *If* the host might move back to the old link and the application can't
> easily recover, then the best thing for TCP to do would be to be
> patient, and keep on retransmitting. (And the IP layer might prevent
> those packets from going out with the invalid source address until the
> host moves back to the same link.)
>
> But *if* the application can quickly and easily recover by creating a
> new TCP connection, the best strategy would be to immediately reset the
> TCP connection so that the application can recreate another one.

'IP layer' may have difficulty determining which type of application
is running currently. I guess the decision (whether to keep tying or
not) would better to be left to application.

> >> The issue of "discard old information" above does have the potential to
> >> break things compared to a non-DNA host today.
> >> Today a host (that only follows 2461/62) will assume it has the same
> >> information until the information times out (with default timers ranging
> >> from hours to weeks).
> >
> > Is this just what implementations do, or is this supported (or even
> > called for) in 2461/2462 (or other specs)?
>
> As stated above, I find no text in 2461/2462 arguing either end of the
> scale (or the middle) for how a host should behave when a link goes down.
>
> I think there is a fundamental tradeoff between being quick to react and
> keep the host's IPv6 addresses stable.
> CPL as well as the DNA solution protocol do go through some extra work
> to come up with a reasonable tradeoff *at the IP layer* between the two,
> and this is why we see things like on a lossy link CPL might not be able
> to conclude a host has moved until after 12 seconds worst case. (But the
> DNA solution can always do it in one RS/RA roundtrip time.)
>
> By doing this, DNA leaves the tradeoff between quick and stable to the
> ULPs to cope with. And we seem to agree that there are some hard
> tradeoffs for TCP and the applications in that space.

agree.

Thanks for your kind consideration.

Best Regards

JinHyeock