RE: [Srvloc-discuss] Multicast, Unicast, port 427 and SO_REUSEADD R - Continued

[Bryant E. <bea...@em...>]

This brings up an issue that I have with RFC 2608 as it stands. The
specification is unclear as to the behavior of the protocol with TCP. What
seems to be clear is the following (please correct any assumptions that I
have made!):

1. TCP is REQUIRED for the DA. Since it does not know what SrvReg/SvrDeReg
packets it will accept, and those packets are not "requested".
2. SA support of TCP/IP is optional, although it is not clear when and when
not (see below).
3. UA support of TCP/IP is optional, depending on its ability to deal with
truncated packets.

The following is unclear from the RFC:

1. Do SAs need to listen for TCP/IP connections? What about non-response UDP
unicast? I would assume that the answer is NO.
2. Do UAs need to listen for TCP/IP connections? What about non-response UDP
unicast? Again, I assume NO.
3. How can a SA decide if it needs to implement TCP/IP if it is based on the
size of packet that it must RECEIVE? The presence of previous responder
lists breaks this logic, as the size of the packet is unknown to the SA.

That leaves the DA as the only agent that needs to actively listen on a
known port.

In the case of a UA re-issuing a request, I believe that the correct answer
is to have the UA open the connection to the sending port of the overflowed
response. In other words, it seems to me that the correct architecture is
have no required ports except for 427 - and that only for multicast
listening. All unicast traffic (UDP or TCP) should be done to the same
host/port that sent the "causing" packet.

Maybe a summary of my arguments is in order. I believe in symmetry. SLP is
very close to a symmetric protocol, and I believe it should be exactly
symmetric in the following sense.

RULES
1. If you want to send a packet and you don't know who to send it to, send
it multicast to port 427.
2. If you are responding to a packet, independent of how you received it,
you reply to the host/port that caused you to send the packet.
3. Rule 2 applies no matter whether the packet you are sending is a request
or a response, and whether you desire to use UDP or TCP.

This means the following:
DA: opens 427 for mc listen. opens ephemeral for mc send, UDP send/receive,
TCP send/receive.
SA: opens 427 for mc listen. opens ephemeral for mc send, UDP send/receive,
TCP send/receive IF required.
UA: opens 427 for mc listen. opens ephemeral for mc send, UDP send/receive,
TCP send/receive IF required.

I believe that these rules and behaviors lead to a more clearly understood
and more clearly implemented protocol.

There are several aspects of the existing RFC that break using these rules:
1. DAAdverts include a host. Technically, this means that it could direct
traffic to a DIFFERENT host than itself - a violation of rule 2 and 3.
2. Configuration (whether text-file based, DHCP based, or other) does not
work with ephemeral ports. This only affects DAs. In my mind, once
configuration of any kind has been done you are free to set the rules
through the configuration. I would still argue that being able to configure
the port is useful.

Note that in the DAAdvert case, rule 2 means that you wouldn't even have to
include the host OR port in the URL - all traffic would go to the host/port
that sent the DAAdvert.

Does this make sense to people?
Bryant

-----Original Message-----
From: Erik Guttman [mailto:Eri...@su...]
Sent: Friday, September 13, 2002 4:00 AM
To: Henrik Eriksson
Cc: 'Erik Guttman'; srv...@li...
Subject: RE: [Srvloc-discuss] Multicast, Unicast, port 427 and
SO_REUSEADD R - Continued


On Fri, 13 Sep 2002, Henrik Eriksson wrote:

> > From: Erik Guttman [mailto:Eri...@su...]
> > Sent: Friday, September 13, 2002 10:33 AM
> 
> I'm sorry to get into this discussion at such a late point, but: 
> 
> > What we can do in this version easily, and I believe its a great idea
> > is to
> >  - require senders always use an ephemeral port
> >  - make it impossible for SAs to receive unicast requests (this
> >    will simplify SAs and the entire model)
> 
> I disagree that this is easily done since it will break the possibility
> for a UA to redo a request over TCP if the response was overflowed. It
> may be a tradeoff that can be made to simplify the protocol but it
> certainly breaks the assumption that SLP behaves the same whether or
> not DAs are deployed.

Agh, you are right.

Erik



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Srvloc-discuss mailing list
Srv...@li...
https://lists.sourceforge.net/lists/listinfo/srvloc-discuss