Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow

From: "t.petch" <[email-masked]>
Date: Tue, 27 Jul 2010 14:37:36 +0200

> ----- Original Message -----
> From: "Javier Ubillos" <[email-masked]>
> To: "t.petch" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 27, 2010 1:06 PM
> Subject: Re: [apps-discuss] Name based sockets - Making individual
> submissionsknow
>
>
> It relates very much :)
> It's the continuation of what was proposed in that article.
>
 <tp>
 In which case, the critiques in
 draft-irtf-rrg-recommendation
 seem appropriate

 </tp>

> // Javier
>
> On Tue, 2010-07-27 at 11:37 +0200, t.petch wrote:
> > How does this relate to
> >  http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf
> > as discussed and critiqued on the RRG list?
> >
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "Javier Ubillos" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Monday, July 26, 2010 11:30 AM
> > Subject: [apps-discuss] Name based sockets - Making individual
submissionsknow

---

From: Graham Klyne <[email-masked]>
Date: Tue, 27 Jul 2010 17:27:02 +0100

Writing as an interested onlooker rather than a proponent, I find it hard to see 
the relevance here.

The scenario there that seems to come nearest is NOL (section 6), for which "At 
the edge network, we introduce a new type of gateway NTR (Name Transfer Relay)", 
which is not (AFAICT) in contention for named sockets.  I understand the named 
socket approach is handled entirely by the application host, so there's no 
change to the IP routing structures that I can imagine.

Generally, I'd say that if the document you cite wants to gain attention outside 
the routing community, it needs to be somewhat more clearly written.  It seems 
to be riddled with acronyms whose meaning is hard to determine or not given 
(what's "CEE" and/or "CES"?).

#g
--

t.petch wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Jul 2010 18:09:03 +0200

----- Original Message -----
From: "Graham Klyne" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Javier Ubillos" <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 27, 2010 6:27 PM

> (what's "CEE" and/or "CES"?).

It is section 15 that I had in mind, which is based on Christian Vogt's paper
which Javier says has evolved into this I-D.  There is a summary and critique
there but I had forgotten that the better critique made it to the mailing list
but not to the rrg I-D.  The aim of all the proposals in the rrg I-D is to
support such as

"Applications are thus relieved of re-implementing features such as
multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and
address management in general."

Murray queried why that was there; well, that was what I saw as the purpose of
name based sockets in the first instance.

Tom Petch

---

From: Graham Klyne <[email-masked]>
Date: Tue, 27 Jul 2010 20:06:24 +0100

Thanks - for some reason I missed that, thinking I'd got to the end.  Oh well.

FWIW, I think the named sockets draft acknowledges what I see as the substantive 
point in the critique (not applicable to all protocols).  And I think I 
(initially) saw the purpose of named sockets in the way you mention.

#g
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Jul 2010 22:57:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Tuesday, July 27, 2010 9:09 AM
> To: Graham Klyne
> Cc: [email-masked]
> Subject: Re: [apps-discuss] Name based sockets - Making individual submissionsknow
> 

My point is that I can't imagine how a client application wanting to reach some other service needs to be aware that it's on a mobile device or behind a NAT, for example, and behave differently.

I get the utility of being able to say "I want to connect to X on port Y" and not having to deal with all the DNS work that might be involved, but the stated premise for the work isn't a pain point I've ever heard of.

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 28 Jul 2010 10:05:26 +0200

> I get the utility of being able to say "I want to connect to X on port Y" and not having to deal with all the DNS work that might be involved, but the stated premise for the work isn't a pain point…

I'm not sure I'm understanding where this is going.
Do I get the point correctly if we are all agreeing that:
Applications should not need to care about network issues, that should
be solved "underneath". 
Mobility, NAT, IPv4&6 and all other ugly network things should be dealt
with by this other "underneath" thing.

Or is some one trying to make a different point that I am completely
missing?

The purpose of name based sockets _is_ to solve all these things, but
also to give the application a receipt that those things _are_ dealt
with, as opposed to shimming-layers, where you get the features "for
free" but the application is just never aware of whether or not th cool
stuff is there or not.

// Javier

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 Jul 2010 02:13:33 -0700

> From: Javier Ubillos [mailto:[email-masked]]
> Sent: Wednesday, July 28, 2010 1:05 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]; t.petch; Graham Klyne; [email-masked]

I believe most things in application space already consider everything you listed as "underneath", except perhaps for knowing what protocol family they're trying to use.  Everything else you've listed already lives in other layers, mostly transport.

The idea of moving DNS resolution out of the socket API is possibly an application area consideration, but it doesn't have anything to do with the things you listed above, and could probably solved with an API layer (a helper library) rather than a whole new socket abstraction.

So my point is that the things you're saying this solves are actually already solved by the existing abstraction of the socket layer.  I think your problem statement doesn't match what you're actually doing.

Section 5 of your document shows an example use.  Essentially what it does, though, is obviate the need to call gethostbyname() or similar.  There's nothing in there about the "underneath" transport stuff.  Comparing that to a current implementation, you can't see any obvious evidence, other than the protocol family, that the application knows anything about the "underneath" stuff in the first place.  Therefore, I don't think you're actually addressing a problem that I can see in this context.

The document either needs a more compelling statement of the problem it's solving, or some examples of code (or perhaps just pseudo-code) that shows the complication that would be alleviated.

I'm also vaguely wondering if this (API definition) is the kind of thing the IETF should do in general, but I suspect I'm up against an opposite precedent on that issue.

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 28 Jul 2010 17:30:14 +0200

Hi, please see responses in-line.

> The idea of moving DNS resolution out of the socket API is possibly an application area consideration, but it doesn't have anything to do with the things you listed above, and could probably solved…

I think I agree with you.
The socket() interface is not the only interface apps work with. In
fact, most applications "out there" already use higher socket
abstractions. Abstractions that do DNS resolution, and usualy provide a
few more features particular to which ever application/protocol it tries
to cater to.
I too think that an helper library is the way to go deployment wize,
whenever the stuff is mature enough, it will "sink in" to the OS and
become a natural part of it.

Consider the socket() API we show an implementation example.
I presume that most other languages/frameworks at some point use a
socket() call. So attacking the problem with a first implementation at
that level seems appropriate to me, more reusable code.

> So my point is that the things you're saying this solves are actually already solved by the existing abstraction of the socket layer.  I think your problem statement doesn't match what you're actua…

I partly disagree.
Yes, there are socket abstractions out there, but I have not met one yet
that is bilateral in some sense. The ones I have come across have been
very specialized.

<snip>

> The document either needs a more compelling statement of the problem it's solving, or some examples of code (or perhaps just pseudo-code) that shows the complication that would be alleviated.

I think you are right, I'll try to address these things in upcoming
drafts.

---

From: "t.petch" <[email-masked]>
Date: Fri, 30 Jul 2010 12:09:51 +0200

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "Javier Ubillos" <[email-masked]>
Sent: Wednesday, July 28, 2010 11:13 AM

> I believe most things in application space already consider everything you
listed as "underneath", except perhaps for knowing what protocol family they're
trying to use.  Everything else you've listed already lives in other layers,
mostly transport.

If only.

The trouble is that application space does deal in things that it never should,
namely the network address, IPv4 or IPv6, stores it, hands it on ... so when the
lower layers, the only ones that should be privy to it, want to change it, for
resilience, recovery, load balancing or any one of a hundred good reasons, they
can't because that pesky application space has taken note of something that it
never should have had knowledge of.

I grew up with international networks where the application API was totally name
based and, when I came to TCP/IP, wondered how a network address sensitive API
could ever work; well, sticking plaster and string has kept it going for a
while, but eventually it stops working, which is what RRG and its various
products are about.  Had name-based APIs been the norm in TCP/IP, then we would
never have had a problem

So I like the idea of a name-based API but it needs name-based referrals to make
it of value.

Tom Petch

> The idea of moving DNS resolution out of the socket API is possibly an
application area consideration, but it doesn't have anything to do with the
things you listed above, and could probably solved with an API layer (a helper
library) rather than a whole new socket abstraction.
>
> So my point is that the things you're saying this solves are actually already
solved by the existing abstraction of the socket layer.  I think your problem
statement doesn't match what you're actually doing.
>
> Section 5 of your document shows an example use.  Essentially what it does,
though, is obviate the need to call gethostbyname() or similar.  There's nothing
in there about the "underneath" transport stuff.  Comparing that to a current
implementation, you can't see any obvious evidence, other than the protocol
family, that the application knows anything about the "underneath" stuff in the
first place.  Therefore, I don't think you're actually addressing a problem that
I can see in this context.
>
> The document either needs a more compelling statement of the problem it's
solving, or some examples of code (or perhaps just pseudo-code) that shows the
complication that would be alleviated.
>
> I'm also vaguely wondering if this (API definition) is the kind of thing the
IETF should do in general, but I suspect I'm up against an opposite precedent on
that issue.

---

From: Javier Ubillos <[email-masked]>
Date: Fri, 30 Jul 2010 15:25:52 +0200

> So I like the idea of a name-based API but it needs name-based

Could you please motivate a little ?
Why and what kind of referral?
The kind being spec:ed in "Generic referral object"?
http://tools.ietf.org/html/draft-carpenter-behave-referral-object-01

To _some_ extent, a DNS record denotes scope (A, AAAA, SRV and so on).
But maybe that dosen't scratch the right itch...

// Javier

---

From: "t.petch" <[email-masked]>
Date: Fri, 30 Jul 2010 16:32:46 +0200

----- Original Message -----
From: "Javier Ubillos" <[email-masked]>
To: "t.petch" <[email-masked]>
Sent: Friday, July 30, 2010 3:25 PM

<tp>
Yes or in
draft-carpenter-referral-ps-00
FTP is the classic use case, a control channel that needs to transfer
information about the end points of an associated data channel.

Harking back to the name based sockets work of the RRG, a different approach is
to split the 128 bits of an IPv6 address and make the lower 64 a stable
identifier using the upper 64 for traffic routing, changing as network
conditions change.  This also needs a new API to go with it.
</tp>

// Javier