Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

["Spencer Dawkins" <spencer@mcsr-labs.org>]

Sigh. Has anyone ever made a helpful suggestion? anyway.

----- Original Message ----- 


> Spencer Dawkins;
>
> > My apologies for not being clearer. What I meant was, multi6
should
> > pick a targer for survivability, whether measured in tens of
minutes
> > (TCP), tens of seconds (HTTP with a human in the loop) or hundreds
of
> > milliseconds (VoIP).
>
> Wrong.
>
> First of all, you confuse timeout to try alternative addresses
> (for HTTP (over TCP) and VoIP) and timeout to disconnect (for
> TCP (including TCP under HTTP).
>
> Then, you properly mention, for both cases of timeout, the target
> value differs application by application that there can be no
> meaningful target defined by multi6.

My point here was that humans-in-the-loop give up orders of magnitude
sooner than FTP over TCP (to use one example). Your point, that
"giving up" may involve different strategies for different
applications, is helpful, but seems orthogonal to my point.

>
> What's necessary is a set of API for TCP/VoIP layers.

I usually understand your terse comments, but not this one. You don't
mean TCP/VoIP, do you? You mean "TCP and VoIP"? If not, I am
hopelessly confused.

>
> > By doing so, communities can consider their needs vis-a-vis the
> > target. If your needs are met by the target, you can rely on
multi6
> > for survivability, and if not, you can start working on
> > special-purpose survivability mechanisms.
>
> Wrong.
>
> In most of the cases, we can rely on TCP for survivability, just
> as TCP is the default mechanism for error free transmission.

If by "most of the cases" you believe that end users will sit quietly
while TCP recovers, over a period of minutes, you and I are not
solving the same problem. In the case of a computer using FTP as part
of a cron job, I agree with you, but my experience is that this
portion of Internet traffic is small and declining.

>
> They are all described in my draft for these years.

I think (to rephrase in terms of my post) you have already chosen a
target for connection survivability (and it's something timeframes
appropriate for TCP), and are expecting applications with a shorter
target to use an API that includes trying alternative addresses before
TCP connections disconnect. That's certainly one alternative. I am
asking that we make our choice explicit, perhaps in a *current*
*working group* Internet Draft...

>
> Masataka Ohta
>
>