At 09:51 09/05/2007, Gorry Fairhurst wrote:
(Sorry for the delay in my response... time is passing faster than it
should... :-) )
* General comment:
The draft argues that services codes allow the decoupling of service
identification from demultiplexing. However, skimming through section
8.1.2 of the DCCP spec, I get the impression that service codes
provide sort of a second-level demultiplexing mechanism. That is,
packets are first demultiplexed based on the port number. If there is
an app listening on that port, *then* the request is demultiplexed
based on the service code. If I am right, then I'm not sure I'd say
that the service identification and demultiplex functions are
actually decoupled.
That is a key point of debate, and one that I'd welcome feedabck.
Note that when the Spec was made, this was simply a proposal. I
believe it's now up to the group to figure out how this will be realised.
I have not yet ben able to see how the servcodes could be exploited
so that a variety of hosts behind a NAT can offer the same service to
the Internet. As far as I can see, even if you use servcodes for
demultiplexing packets, you'll need "well-known servcodes".
As far as I can see, in order for several hosts behind a NAT to offer
the same service to the Internet you'd need a directory service like
like DNS SRV RRs, portmapper, etc.
But please let me know if I am missing something.
Page 1, Abstract:
"The DCCP
Service Code can also enable more explicit coordination of services
behind NATs and firewalls."
s/enable/enables/ (or s/Code/Codes/)
Changed:
The use of a DCCP Service Code can also enable more explicit
coordination of services behind NATs and firewalls.
Great. BTW, see the above comment.
Page 5, Section 2:
"Section 3 describes the use of Service Codes by end hosts and
network middleboxes. "
s/end hosts/hosts" (or s/end hosts/end systems/) (there are other
instances of this)
Looking at other RFCs, the term "end host" is not uncommon, but I am
happy to move to "host" if that eases readability. Done.
Of the top of my head, end-system and intermmediate-systems come from
osi, while host and router from the internet. But I didn't recall
reading "end host". (No big deal, anyway).
Page 9, Section 3.4:
"This operation could resemble that of "portmapper" or "inetd". "
I'd just mention inetd. Portmapper is directory service. It resolves
"service names" into "port numbers" (IIRC).
Yes, exactly, I was imaging something more like portmapper that had
a database of "service names" (aka codes) that could operate as a
daemon. Are there better words for this?
For this example (i.e., "....however this service does not need to be
permanently running at the Server. The arrival of a ....") I think
you should delete the reference to portmapper, and mention only
"inetd" (that's the program that does what you are describing here).
Page 16, Section 9.2:
|0x50455246| PERF |5001| Performance tests (e.g. | * |
| | | | iperf, ttcp, ...) | |
Maybe a port could be assigned to performance tests, and the service
code could identify the specific tool/service for actually assessing
performance?
Not sure I understand this, please say more.
If we'll be using services codes for "second-level" demultiplexing,
and you allocate a specific port (5001) for performance tests, you
may use difference services codes to specify the specific test
service you want to use. (I am assuming there are different tests
that you can perform, using different tools/techniques....). Does
this make any sense?
In the "4.2. Standard Support" case receivers demux based only on
port, so these simplest receivers would have no way of associating
these sessions with the app except by using the service code.
However this is permitted in the method in 4.3.
-----
As an aside on this point it would be good to define a specific
service code that could be used to diagnose the demux/association
problem, and identify if a remote server may determine application
based on service code (even when another service is listening on the
same port),
i.e. perhaps we could define a set of two service codes specifically
allocated to the same port, but designed to contact different servers, e.g.
ECHS on port 7 - e.g. which could return a non RFC862 repsonse?
Is this cool, stupod, helpful or silly?
I think this is pretty cool (probably even *needed*), and would make
the transition to your proposed use of servcodes much smoother.
Kindest regards,
--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
