Subject: RE: [Simple] Message Sessions: msrp: URI issues

From: Adam Roach <[email-masked]>
Date: Mon, 7 Apr 2003 20:49:03 -0500

> 	You may not be aware that Roy Fielding is currently
> working on an update to 2396, which is the current document
> describing URI generic syntax.  You may want to review
> his draft: draft-fielding-uri-rfc2396bis-01.txt, as it clarifies
> a number of issues with the previous document.

Thanks for the pointer. I knew such work was starting, but haven't
had time to read it in detail yet. My cursory read of it seems to
support the suggestions I made.

My proposed syntax change, that we not use the form
<userinfo>@<host>:<port>, seems to be borne out as advisable
by the description in section 3.2.2 that the "userinfo" typically
contains "a user name and, optionally, scheme-specific information
about how to gain authorization to access the server." The current
message sessions draft isn't putting a user name in the "userinfo"
portion; it's putting a resource identifier. Section 3.3 would point
to the most common convention being using the path component of a
URI for such purposes.

The comparison rules I propose are essentially those described
in Section 6 of the draft. I omitted default port comparisons,
because I don't think we want a default port. I omitted path
normalization because it doesn't apply to the type of resources
being identified. Escape normalization might be worthwhile, but
it would probably be cheaper to specify that resource identifiers
must be taken from a safe subset, such as "unreserved".

Are there particular suggestions put forward by the current
URI draft that you think my suggestion seems to run afoul of,
or did you just want to make certain I was aware of the ongoing
work?

> 	There is also a fairly long history around how to
> react when you get multiple RRs back to a query in
> the DNS.  

My understanding is that, at least in the case of A records,
the bulk of that history has entailed the resolver and its
user doing pretty much whatever they wanted with the list
records.

> I'd suggest starting with RFC 1794, which
> has a good description of the ways in which the DNS
> does and does not support predictive ordering. In general,
> though, it's probably good to be aware that some systems
> are configured to load balance by shifting the response
> order.

Right. I've been aware of 1794 for a while. The goal
of those endeavors, to my understanding, was the ability
to support load balancing in the DNS without having to
add support to any existing applications. In fact, it
specifically discusses the issue of client-side reordering.
RFC 1034 also talks about resolver library reordering of RRs.

I was under the impression that 1794 wasn't widely implemented
for the reasons cited in RFC 2782. In particular:

   "[T]he actual load on typical servers changes much too
    quickly to be kept around in DNS caches."

What I was proposing was essentially saying, "when implementing
DNS resolution for this protocol, you will use this particular
reordering", which can be done at the application layer. I was
trying to avoid the complexity and signalling overhead of using
SRV (since we gain very little from the bulk of SRV's features
under the circumstances in which MSRP will be used), while still
providing some modicum of load distribution.

Do you think my suggestion is inadvisable?

/a
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Apr 2003 09:52:03 -0700

Hi Adam,
	Some replies inline.

> must be taken from a safe subset, such as "unreserved".

The choices here must be pretty carefully documented, especially
for things like the exclusion of escape normalization.  This isn't
to say you can't specify it that way, only to point out that during
the review cycle external to the WG, this is going to get questioned.
If the draft covers the ground, you save time later.

> or did you just want to make certain I was aware of the ongoing

The latter; it's a clearer doc at this point, and working from it
is easier (and depending on timing, it may be the reference
when the proposed URI scheme is evaluated).

> Do you think my suggestion is inadvisable?

I don't think I'd use the term "inadvisable", but I don't think it 
quite gets
you what you want.  The interaction of a server supplied ordering
(which may be at least naive round-robin) and client-side random 
selection
does not get you to a well-defined state for load distribution.  If you
want load distribution, using RRs for which a mechanism has been
defined makes sense.  If you feel like you can do without it, or feel
like the load distribution can be handled by server ordering, then
selecting RRs which do not have explicit methods for it may
be okay.  That just implies the system can live with whatever
the usual selection mechanism happens to be.

In either case, an explicit choice is valuable, and I appreciate your
putting time into thinking about how to balance the features.

							regards,
									Ted Hardie

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Apr 2003 01:06:26 -0400

Ted Hardie wrote:

> I don't think I'd use the term "inadvisable", but I don't think it quite 
> gets
> (which may be at least naive round-robin) and client-side random selection

I think there is reason in our case to believe that relays will vary in 
capacity, and that we can benefit from the type of load balancing that 
SRV can provide.

Adam, you talk about the "signalling overhead" of SRV. I dont know what 
that means. SRV records should not generally result in additional DNS 
traffic compared to A records, since the server will generally return 
the A records in the response to the SRV query, so that they are cached 
in the local resolver when the client queries for them. I'll further 
note that since we expect SIP to be the main (if not only) customer for 
message sessions, every endpoint is already going to have SRV, so there 
is no additional implementation burden here.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "James Undery" <[email-masked]>
Date: Fri, 25 Apr 2003 21:31:09 +0100

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>

> is no additional implementation burden here.

I think what Adam means here is SRV RR should point to CNAME RRs, however,
as any decent DNS implementation will resolve the CNAME RRs to A(AAA) RRs in
an additional answer this is moot and you are 100% right it's a non issue.

James