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

From: masataka ohta <[email-masked]>
Date: Mon, 03 Nov 2003 15:12:27 +0900

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.

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

> 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.

They are all described in my draft for these years.

							Masataka Ohta

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 3 Nov 2003 06:26:12 -0600

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

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

> 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.

> 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...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Nov 2003 14:43:06 +0100

> applications, is helpful, but seems orthogonal to my point.

Users giving up before applications or protocols is a feature rather 
than a bug. When Apple first came out with its Safari web browser, it 
would only wait 30 seconds for a page to load. Now for normal pages 30 
seconds is a very long time, so this seemed to make sense. (I'm usually 
much more impatient than 30 seconds, though.) However, some types of 
pages, such as very long ones or ones that generate a lot of work for 
the server (searching for a flight online...) need more than 30 
seconds. I that case, the user will wait. Having the application give 
up when the user knows useful results are still forthcoming is 
infuriating.

So as long as the user has the option to terminate the session and 
retry, there shouldn't be any problems.

> solving the same problem.

So what is it you want to do to avoid this situation?

> In the case of a computer using FTP as part

I don't think _any_ type of traffic on the internet is declining in 
absolute terms.  :-)

---

From: masataka ohta <[email-masked]>
Date: Mon, 03 Nov 2003 23:04:13 +0900

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.
>>

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.

> mean TCP/VoIP, do you? You mean "TCP and VoIP"? If not, I am

I mean TCP, VoIP or any application/transport where notion of timeout
can be found.
 
>>>target. If your needs are met by the target, you can rely on
> 
> multi6
> 

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.

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

That's not my choice.

						Masataka Ohta