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

[Fernando Gont <fgont@softhome.net>]

At 12:07 15/07/2004 -0700, you wrote:

> > The -02 draft suggests, basically, that IPv6 Destination Unreachable is a 
> > hard error during connection setup, so that the application can cycle 
> > through different addresses.

Note that while while the proposal *is* to make TCP react to soft errors, 
conceptually we're *not* saying that destination unreacheables are now 
considered "hard errors".

Please have a look at draft-gont-tcpm-tcp-soft-errors-00.txt, which 
contains a somehow expanded discussion of the TCP stuff.

It says:

---- cut here ----
4.1  Changing TCP's reaction to soft errors

   As discussed in Section 1, it may make sense for the fault recovery
   action to depend not only on the type of error being reported, but
   also on the time the error is reported.  For example, one could infer
   that when an error arrives in response to opening a new connection,
   it is probably caused by opening the connection improperly, rather
   than by a transient network failure.  [8]
---- cut here ----

That means, we modify TCP fault isolation policy on the connection 
establishment phase, rather than changing the "meaning" of the error itself.


> > But RFC 1122 also says that TCP "SHOULD make the information [about the 
> > soft error] available to the application".  This shows a way out of the 
> > conflict.

IMHO, this was okay when applciation programmers were more knowledgeable 
about networking and protocol specifics.

Should we *nowadays* bother an *application* programmer with TCP soft/hard 
errors?
I don't think so.

The proposed solution provides a work around without having to bother the 
application programmer. Furthermore, the fix would kick in without adding 
any extra logic to existing applications.


> > We can leave IPv6 Dest Unreach a soft error, like IPv4 Dest Unreach, 
> > while still supporting address cycling.  Simply specify that TCPv6 stacks 
> > SHOULD provide an API by which the application can request that soft 
> > errors end the connection right away (one form of 'making the information 
> > available').

I don't think this soultion would be quite acceptable nowadays.If 
application programmers were to learn more stuff on an API, then it should 
probably be about a brand-new higher level API, that would hide all these 
details from them. And from then on, we could "fix" this sort of "problem" 
without any impact on applications.


> >  This change is more incremental than the change currently proposed, and 
> > less invasive to the stack (no worries about SYN-SENT/SYN-RECEIVED state 
> > and so forth).

Not sure what you mean.

BTW, Thanks so much for your comments!


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