Re: [tcpm] Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt

[Eddie Kohler <kohler@cs.ucla.edu>]

Seems like these two comments are in conflict:

> IMHO, requiring an application programmer more knowledge about 
> networking and protocol specifics (soft and hard errors, etc.) is not a 
> good idea.
and:
> He's still thinking about address-cycling being performed by the 
> application.

If the app cycles between addresses, then the app needs more knowledge about 
networking than most currently do.  The TCP option is incremental on top of 
address cycling.

> Of course, if you provided application programmers with a higher-level 
> API, all the soft errors and address cycling issues could be handled 
> bellow the application.

We agree!

Here's my proposal.

1. "Kernel" socket APIs for TCP are extended with an option that allows the app 
to specify whether "soft" errors should be treated as "hard".

2. A higher-level API is designed that handles multi-protocol DNS resolution and 
address cycling, and that calls the "kernel" socket API as appropriate to turn 
"soft" errors into "hard" ones during connection setup (_iff_ there are multiple 
addresses to try).  In pseudocode:

     open_socket_from_name(DNS_name) ::=
         get list of addresses;
         create socket;
         if (more than one address) {
             // Address cycling: first time through, treat soft errors as hard,
             // so cycling happens faster.
             make soft errors hard on socket;
             for (each address) {
                 try connecting to current address;
                 if (connect succeeded) {
                     make soft errors soft on socket;
                     return socket;
                 }
             make soft errors soft on socket;
         }
         // Second time through, treat soft errors as soft, to avoid failing.
         // Alternately might cycle through addresses a number of times until
         // some timeout occurs.
         for (each address) {
             try connecting to current address;
             if (connect succeeded)
                 return socket;
         }
         destroy socket;
         return connection failure;

This type of structure seems like the right thing for many apps, but not all. 
But there are a lot of potential parameters, and experience is required.  So you 
should only specify it in a library API.

Eddie