Re: [tcpm] TCP, multiple addresses and soft errors when connecting

[Pekka Savola <pekkas@netcore.fi>]

I've been waiting for other comments on this, but none have emerged 
so...

What I propose as a way forward for this specific Informational 
document:

 1) state the reasons why this specific connect() etc. behaviour is 
desirable (read: why many vendors have already done that), and what 
drawbacks it could have (if any), and

 2) state the desire for getting a better higher-level API which would
handle all of this and much more (instead of/in addition to 1), but
mention why this is not an only practical solution.

Does this sound reasonable and well-balanced?

On Mon, 22 Mar 2004, Fernando Gont wrote:
> At 16:39 20/03/2004 +0200, Pekka Savola wrote:
> 
> > > Does it really make sense to handle the whole connection establishment
> > > issue inside the app, instead of inside the API itself?
> >Those are the core APIs we have today.  We could have better ones, but
> >IMHO I think we need to fix problems in the current ones as long as we
> >don't have a widely-deployed alternative.
> 
> IMHO, there are two points to note:
> 
> * If you fix the current ones so that their behavior is "acceptable" to the 
> application programmer, then it'll be harder to introduce a new API. People 
> is reluctant to change, so they must have a reason for learning a new API. 
> If you try to fix the current one, they will find fewer reasons for the change.
> 
> * You said "we don't have a widely-deployed alternative". Unless you meant 
> "we don't have a well-tested alternative", I'd say that it's a 
> chicken-and-egg problem. That means, for an API to be widely deployed, 
> people would have to use it. And for people to use it, they should be able 
> to find a good reason to do it.
> 
> Yes, I'm aware that my proposal my sound as a long-term solution. But, 
> IMHO, it will certainly be harder to introduce a new API if you actually 
> want to do it "in long term".
> I guess "timing" is an issue, here.
> 
> 
> 
> > > I think that if we're debating this, we're implicitly assuming that
> > > applications want to connect to say www.example.com, and not one specific
> > > IP address to which it maps to.
> > >
> > > So why not implement such a "higher-level" connect(), and handle all the
> > > relevant issues inside the API?
> >
> >Defining such APIs is probably beyond the scope of the work we can do,
> >and the things we can fix except in the 5+ year timeframe.. but if I
> >get you right, you're proposing that instead of:
> >
> >  1) getaddrinfo() or gethostbyname() and connect for one address,
> >[where, arguably, TCP retry timeout could be warranted -- I don't
> >think so myself, but you could argue for it]
> >
> >  2) getaddrinfo() / gethostbyname() loop to connect to one address
> >[where TCP retry timeout could not be warranted]
> >
> >You'd be proposing to create a new function to accomplish 2) in such a
> >manner that it would also react to ICMP messages, etc?
> 
> Exactly.
> 
> Then, within that function, each individual connect() could react to ICMP 
> messages a
> as you proposed, but if all addresses fail because of ICMP errors, it could 
> let TCP retry in the hope the transiet problem will dissappear.
> 
> 
> [....]
> > > Doesn't the problem really have to do with having applications performing
> > > such a low-level action?
> >
> >At some point, someone has to decide which behaviour is desirable.
> >Isn't this only hiding the same policy decision inside an abstraction
> >layer
> 
> Yes, but even when the difference may sound subtle, IMHO it's not.
> Having that abstraction layer is what let's you choose a policy, without 
> having the risk of causing any harm to existing apps.
> That way, if you ever need to change the low-level-connect() behavoir for 
> whatever reason, you could still do it. As far as the high-level connect() 
> behaves the same, there would be no problem.
> 
> Think about it. Why should an application programmer care about TCP 
> retries, ICMP erros, an the like?
> In the same way, why should he care about setting "strange" options such as 
> SO_REUSEADDR on his listening socket?
> Should *he* really handle byte-ordering issues  by means of htons() and the 
> like?
> 
> 
> >-- and the same could be achieved by e.g. a setsockopt() flag?
> 
> Strictly speaking, you *could* do that. But then you'd have all programmers 
> implementing themselves a function you could provide them.
> You'd have all them implementing the getaddrinfo()/gethostbyname() loop, 
> setting a strange socket option, etc. Why not provide them with a 
> well-tested function, and let them spend their time implementing their 
> application itself?
> 
> 
> 
> >(I don't deny that better APIs would not hurt, but we still seem to
> >require low-level C-like primitives, and unless there are additional
> >ones implemented there, we still have to fix the problems somehow..)
> 
> Well, the low-level ones could be provided as part of the new API.
> 
> Or along with the providing a new API, the current one could be modified as 
> you suggest. It wouldn't hurt too much if the *low-level* API aborted a 
> connection establishment because an ICMP error is received. Being a 
> *low-level* API, you'd be suppossed to know the details behind the function.
> 
> Best Regards,
> 
> 
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> 
> 
> 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings