[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Spencer;

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

Sigh...

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.


Your mistake here is that you said "HTTP", which, just as "TCP", does
NOT involve human beings.

Even if you have said "web browser application with a human in the
loop", you are still wrong. See below.

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.


I mean TCP, VoIP or any application/transport where notion of timeout
can be found.

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.


Typical end users do not wait timeout of a web browser and just push
"resend" or "stop" button.

The users have their own timeout controlled by neither TCP, HTTP or
web browser and definitely not by multi6 WG.

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),


No. No timeframe can be assumed at the IP layer, as there is no
notion of time (except for maximum TTL of 255 seconds of IPv4, which
is not useful here).

and are expecting applications with a shorter
target to use an API that includes trying alternative addresses before
TCP connections disconnect.


Wrong. Most applications do nothing and just expect TCP try
alternative addresses, though VoIP won't rely on TCP, which
is why I wrote "TCP/VoIP".

That's certainly one alternative. I am
asking that we make our choice explicit, perhaps in a *current*
*working group* Internet Draft...

That's not my choice.

Masataka Ohta