Re: I-D on Registry for tv:URIs

Lisa's October Apps Area Activity

Service vs. Port vs. SRV (following Eliot's presentation)

Folks,

This is in response to Eliot's presentation this morning, in the AppsArea and it 
is merely intended to solicit comment:

I have always understood the construct of Well-Known Ports as being a means of 
standardizing an efficient rendezvous mechanism, for clients to find servers. -- 
without quibbling about the terminology that might better cover use in 
peer-to-peer scenarios.

This creates a means of associating a "channel" to a protocol, in order to 
achieve a "service".

By way of example, SMTP and SUBMIT are (essentially) the same protocol, but they 
are different services (initial MUA-MSA posting, versus MSA/MTA or MTA-MTA or 
MTA/MDA relaying.)

In effect, Port 25 vs. Port 587 define the two different sservice.

SRV clearly serves as a more generalized and long-term mechanism for defining a 
service (and, gosh, doesn't that make the choice of the RR's name particularly 
nice?)

As Eliot notes, however, this builds a dependency on the DNS into the underlying 
construct of IP-to-IP rendezvous.  While most of the Internet use today already 
has that dependency as a pragmatic realtion, for other reasons, it is not built 
into the basics of Internet infrastructure as a formal requirement.

So changing our model to focus on SRV has some interesting implications.

Thoughts?

d/
--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Re: Service vs. Port vs. SRV (following Eliot's presentation)

At 11:03 AM -0800 11/6/06, Dave Crocker wrote:

>  SRV clearly serves as a more generalized and long-term mechanism 
> for defining a service (and, gosh, doesn't that make the choice of 
> the RR's name particularly nice?)
>
>  As Eliot notes, however, this builds a dependency on the DNS into 
> the underlying construct of IP-to-IP rendezvous.  While most of the 
> Internet use today already has that dependency as a pragmatic 
> realtion, for other reasons, it is not built into the basics of 
> Internet infrastructure as a formal requirement.
>
>  So changing our model to focus on SRV has some interesting implications.

The implications may depend on who is included in "our" (in "changing 
our model").  A lot of application-level protocols already do, as you 
note, depend on DNS.
--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I distrust those people who know so well what God wants them to
do, because I notice it always coincides with their own desires.
    --Susan B. Anthony

Re: Service vs. Port vs. SRV (following Eliot's presentation)

> Folks,

> This is in response to Eliot's presentation this morning, in the AppsArea and it
> is merely intended to solicit comment:

> I have always understood the construct of Well-Known Ports as being a means of
> standardizing an efficient rendezvous mechanism, for clients to find servers. --
> without quibbling about the terminology that might better cover use in
> peer-to-peer scenarios.

I think you're talking past each other here. You're referring to our practice
of saying things like "SMTP servers listen on port 25 by default" or "HTTP
servers normally listen on port 80". Eliot is talking about ports with
numeric values less than 1024 being handled distinctly from those above
1024.

I am complete agree with Eliot that the "below 1024 are special" notion's time
has long since past. It made sense back in the mainframe era, but it was over
the minute we started putting machines directly under the control of random
users.

I certainly don't want to abandon the practice of defining ports associated
with specific services and I don't think Eliot is saying that either.

> ...

> SRV clearly serves as a more generalized and long-term mechanism for defining a
> service (and, gosh, doesn't that make the choice of the RR's name particularly
> nice?)

> As Eliot notes, however, this builds a dependency on the DNS into the underlying
> construct of IP-to-IP rendezvous.  While most of the Internet use today already
> has that dependency as a pragmatic realtion, for other reasons, it is not built
> into the basics of Internet infrastructure as a formal requirement.

> So changing our model to focus on SRV has some interesting implications.

I wasn't entirely clear on what Eliot was trying to say about SRV records.
Perhaps someone could recap that here?

				Ned

Re: Service vs. Port vs. SRV (following Eliot's presentation)

> On Mon, 6 Nov 2006, Ned Freed wrote:
> >> This is in response to Eliot's presentation this morning, in the
> >> AppsArea and it is merely intended to solicit comment:
> >
> >> I have always understood the construct of Well-Known Ports as being a
> >> means of standardizing an efficient rendezvous mechanism, for clients
> >> to find servers. -- without quibbling about the terminology that might
> >> better cover use in peer-to-peer scenarios.
> >
> > I think you're talking past each other here. You're referring to our
> > practice of saying things like "SMTP servers listen on port 25 by
> > default" or "HTTP servers normally listen on port 80". Eliot is talking
> > about ports with numeric values less than 1024 being handled distinctly
> > from those above 1024.

> Elliot was talking about both in his presentation.  The first bit was this
> whole thing involving ports 0 to 1023 (which the registry calls "Well
> Known Ports").  The second bit was the recommendation that new protocols
> should consider using SRV instead of having a particular port number.

> > I am complete agree with Eliot that the "below 1024 are special"
> > notion's time has long since past. It made sense back in the mainframe
> > era, but it was over the minute we started putting machines directly
> > under the control of random users.

> I agree.

> > I certainly don't want to abandon the practice of defining ports
> > associated with specific services and I don't think Eliot is saying that
> > either.

> He didn't suggest that, as it's impossible for protocols below DNS or that
> cannot afford to depend on DNS.

> > I wasn't entirely clear on what Eliot was trying to say about SRV records.
> > Perhaps someone could recap that here?

> SRV records good:
>   - provides fallback/load-balance location mechanism
>   - avoids tight port # binding
>   - namespace of assignments is strings (that can be a DNS label) instead
>     of 16bit numbers

> SRV records bad:
>   - add dependency on DNS
>   - add latency on first connect, maybe later
>   - complexity

I agree with all of this. On balance I don't think we use SRV records often
enough, but I also think there's a point past which they'd be overused.

				Ned

Re: Service vs. Port vs. SRV (following Eliot's presentation)

Randall Gellens wrote:
>> So changing our model to focus on SRV has some interesting implications.
> 
> The implications may depend on who is included in "our" (in "changing our
> model").  A lot of application-level protocols already do, as you note,
> depend on DNS.

sorry for being fuzzy.  i mean 'out model' as in 'our transport/ip' model, which
currently does not rely on the DNS.  I believe that re-targeting service
selection to be in terms of SRV records changes this.  (I'm not offering an
opinion about whether to do this, but am merely noting the import -- and I am
merely echoing what others have said before.)

Ned Freed wrote:
> I think you're talking past each other here. You're referring to our practice
>  of saying things like "SMTP servers listen on port 25 by default" or "HTTP 
> servers normally listen on port 80". Eliot is talking about ports with 
> numeric values less than 1024 being handled distinctly from those above 1024.

I heard him make comments that seemed to clearly indicate that *some* 
infrastructure service almost certainly need to stay with port numbers.  He 
cited examples.

> I am complete agree with Eliot that the "below 1024 are special" notion's
> time has long since past.

I too heard the reference, but didn't hear any of the rest of his comments 
seeming to be related to the security function that the 1024 block was initially 
used for.  So I decided the 1024-is-special reference was useful mostly as an 
introduction to the discussion rather than intended to be a technical focus on 
what followed.

Might not be what Eliot meant, but it worked for me...

> I certainly don't want to abandon the practice of defining ports associated 
> with specific services and I don't think Eliot is saying that either.

Actually, I heard a suggestion that we move to using SRV *instead of reserved 
port numbers* as a long-term model.

That the model might apply in some cases and not others (as per the 
infrastructure services point, above) seemed like an issue for further discussion.

d/
--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Re: Service vs. Port vs. SRV (following Eliot's presentation)

Ned Freed wrote:
> ..., but I also think there's a point past which they'd be overused.

Can you characterize that limit in some technical or administrative terms?

d/
--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Re: Service vs. Port vs. SRV (following Eliot's presentation)

> Ned Freed wrote:
> > ..., but I also think there's a point past which they'd be overused.

> Can you characterize that limit in some technical or administrative terms?

I think Phillip's pro and con lists are a start at expressing the criteria for
making a selection between the two mechanisms. There are some clear cases at
the edges, e.g. services that run "below" DNS or which have real time response
requirement cannot use SRV, and services that need lots of redundant servers
with fallback and prioritization should use SRV instead of a bunch of A
records.

We specified use of SRV records in the MSGTRK work and it seems entirely
appropriate to use them in that case. I don't have a candidate protocol
currently being developed in mind where I'd like to see SRV records used, but
sooner or later there will be one.

				Ned

Re: Service vs. Port vs. SRV (following Eliot's presentation)

On Mon, 6 Nov 2006, Ned Freed wrote:
>> This is in response to Eliot's presentation this morning, in the 
>> AppsArea and it is merely intended to solicit comment:
>
>> I have always understood the construct of Well-Known Ports as being a 
>> means of standardizing an efficient rendezvous mechanism, for clients 
>> to find servers. -- without quibbling about the terminology that might 
>> better cover use in peer-to-peer scenarios.
>
> I think you're talking past each other here. You're referring to our 
> practice of saying things like "SMTP servers listen on port 25 by 
> default" or "HTTP servers normally listen on port 80". Eliot is talking 
> about ports with numeric values less than 1024 being handled distinctly 
> from those above 1024.

Elliot was talking about both in his presentation.  The first bit was this 
whole thing involving ports 0 to 1023 (which the registry calls "Well 
Known Ports").  The second bit was the recommendation that new protocols 
should consider using SRV instead of having a particular port number.

> I am complete agree with Eliot that the "below 1024 are special" 
> notion's time has long since past. It made sense back in the mainframe 
> era, but it was over the minute we started putting machines directly 
> under the control of random users.

I agree.

> I certainly don't want to abandon the practice of defining ports 
> associated with specific services and I don't think Eliot is saying that 
> either.

He didn't suggest that, as it's impossible for protocols below DNS or that 
cannot afford to depend on DNS.

> I wasn't entirely clear on what Eliot was trying to say about SRV records.
> Perhaps someone could recap that here?

SRV records good:
  - provides fallback/load-balance location mechanism
  - avoids tight port # binding
  - namespace of assignments is strings (that can be a DNS label) instead
    of 16bit numbers

SRV records bad:
  - add dependency on DNS
  - add latency on first connect, maybe later
  - complexity

Philip Guenther