Re: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface

[John Leslie <[e-mail]>]

R?mi Despr?s <[e-mail]> wrote:
> 
> Stuart Cheshire added to the list (AFAIK, the leading advocate of 
> connect-by-name).

   Hi, Stuart!

> Joe Touch wrote :
> 
>> I'm not sure this is a desirable objective.
>>
>> When you specify a name, you're not specifying a single address; you're
>> specifying any one of a set of addresses. It's presumed that these are
>> equivalent, but not that they are to the same host. A name-based system
>> could easily end up with a sequence of connections going to different
>> hosts.

   True.

>> That's avoided today as:
>>
>>	adr = first(dns("name"))  -- or adr = pickone(dns("name"))
>>	connect(adr)
>>	connect(adr)
>>	connect(adr)
>> There doesn't seem to be a way to achieve this with:
>>
>>	connect("name")
>>	connect("name")
>>	connect("name")
>>
>> This destroys the utility of HTTP cookies, e.g.

   Only if both ends are blind to the issue...

> Note that:
> - If backward compatibility is maintained, as required in the proposal, 
>   a name-capable API doesn't imply that it be address-unable.
> - Connect-by-name is already mentioned for Shim6 in RFC 5533 - sec. 13, 
>   (a way to save time when multiple addresses have to be tried for a
>   given domain name)
> 
> Applications that may depend on successive connections to go to the same 
> host, they can use:
> 	ConnectByName(name) which returns the chosen adr
> 	Connect(adr)
> 	Connect(adr)
> 	Connect(adr)

   That's one way to think about the problem...

> The useful novelty ahead is IMHO the following:
> - If a connection initiator includes its domain name in its connection 
>   request (e.g. in a TCP option) the API of the reached application, if
>   it is name-capable, provides both the address AND the name of the 
>   connection initiator.

   I would argue that any ConnectByName API SHOULD contain the _name_
by which your end wants to be known by the other end. ("Connect" should
imply establishing a "connection" IMHO.)

> - A consistency check between address and name is done by the transport 
>   layer before connection acceptance. This check needs only a DNS query.
>   It is therefore compatible with DNS dynamic updates and DNSSEC (no
>   need for a DNS supported reverse mapping).

   I'm not sure that's necessary, but it's certainly appropriate to
discuss what consistency checks _are_ necessary...

   I would argue that our charter calls for work on
" 
" e. An extended API describing how applications can exploit additional
"    features of multipath transport. While MPTCP needs to be usable
"    without any application changes, this API should be an optional
"    extension that provides access to multipath information and enables
"    control over the usage of multipath.

and further that "an extended API" should enable extension to protocol
extensions yet to be defined. Thus:

- the same "extended API" should be able to request legacy TCP, MPTCP,
  or even other transports (such as SCTP);

- the "extended API" should be able to use DNS names or some other name
  format to be defined later (for one example, IPv6 "address" space is
  large enough to contain many "name" spaces);

- the "extended API" should return an indication of which names and/or
  addresses the other end of the connection uses.

--
John Leslie <[e-mail]>