Re: [tcpm] TCP, DCCP, v6, and ICMP soft errors [draft-ietf-v6ops-v6onbydefault-01]

[Fernando Gont <fernando@gont.com.ar>]

At 10:04 18/07/2004 -0700, Eddie Kohler wrote:

> The best kernel APIs provide mechanism, not policy, since policy changes 
> and different apps want different policies.

We're talking about a fault isolation policy in a transport protocol. An 
application should not be concerned with it.


> In my opinion draft-gont-tcpm-tcp-soft-errors codifies for all apps a 
> policy that, if implemented, may/will reduce user-visible network 
> connectivity.

As stated both in the drafts and in my previous posts, the change in the 
policy is meant only for connections in the SYN-SENT and SYN-RECEIVED states.

OTOH, if it's a non-interactive application that's using the connection 
(say, a mailserver), the application itself will trigger a retry some time 
later. If it was an interactive application, then a delay was not 
acceptable, anyway.


> Therefore it should not be accepted; a new draft should provide a 
> "mechanism" for implementing the soft-error behavior you need,

"mechanism"??


> discuss how to use that mechanism,

Again, we're trying to solve problems in *applications*.


> and also potentially talk about a higher-level, library API that DTRT by 
> default.

Will include some stuff about a Higher-Level API in the next revision of 
the draft.


> Also, talking about "default behavior" and ease of app construction is a 
> little disingenuous since there's no real installed base.

I have no data about what the "real installed base" is.
In any case, the "default behaviour" is crucial to how long it will take 
the fix to be used by programmers.


>   Only apps that implement address cycling need the new behavior; this is 
> a small set.  Apps that don't cycle addresses: now there's an installed base.

Address-cycling is well-known practice. RFC 1122, dated 1989, says 
applications SHOULD be prepared to do cycle on a list of IP addresses.


> If anyone had practical data on Destination Unreachable errors -- in 
> particular, how transient they tend to be for today's hosts -- this would 
> be a great time to speak up.

I disagree. No one is saying ICMP Unreacheables are hard errors. We're just 
saying that there's a potential problem of long delay in connection 
attempts (not only in v6, but could also be the case in IPv4), and that 
this problem could be worked around by changing TCP's reaction to soft 
errors in the connection *establishment* phase.


> If Dest. Unreachable is frequently transient, that strengthens my 
> case.  If it's very infrequently transient, that strengthens 
> draft-gont-tcpm-tcp-soft-errors.

That would strength your case if someone were proposing to abort 
connnections in *any* state.

Best Regards,


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org