[dcp] Re: dcp digest, Vol 1 #18 - 1 msg

[Dan Duchamp <djd@cs.stevens-tech.edu>]

On Wed, 27 Mar 2002 dcp-admin@ietf.org wrote:

> We are looking for people to do research implementations of DCP.  We
> understand that the DCP specifications are quite likely to change as
> we progress, so the point of an implementation would be to learn
> more about real-world protocol issues that we have overlooked.

My student, Marek Zawadzki, has been doing such an implementation this
term.  He is adding DCP to Linux 2.4.  The work has generated a few
questions about feature negotiation:

1. Do you have an intended model for how to handle re-negotiation of
features for an already-open connection or is this intentionally left
as a variable for the implementor?  Re-negotiating features that may
govern the very packets that contain the negotiation seems tricky.

On one hand, it is tempting to simplify an initial implementation by
stopping the connection in order to do re-negotiation.  However,
because negotiation may be non-terminating, the initial negotiation
started when the connection is established may still be going when
both sides reach the open state.  Therefore, we face pressure to
handle this case even in our initial implementation.

2. It seems possible for one side to use a feature the other side is
not prepared for yet.  From the diagram on p. 24 it seems that, after
receiving 'Ask', DCP_A can send 'Answer' and set the value of the
feature.  But what if 'Answer' is lost and DCP_A starts sending
packets whose proper handling requires the new feature?

3. The text on page 26
	octets "1, 6, 1, 1, 2, 3": Ask option (1)
should indicate the Ask option as being 33, not 1, right?

In general, I am concerned whether it is sound design (1) to have a
non-terminating feature negotiation sub-protocol, and (2) to permit
negotiation of features while affected packets may be in flight.  Even
if there is an argument for why it works out for the current list of
features on page 21, implementation of some future feature may be
negatively affected.

Would it be better to have a design that:
1. uses a bounded-length negotiation protocol, one of whose outcomes
is "failed negotiation"?
2. when re-negotiation is necessary, stops the connection,
re-negotiates, then re-starts?
at least for version 1.0 of the protocol?

------------
Dan Duchamp			Email: djd@cs.stevens-tech.edu
Computer Science Department	WWW: http://www.cs.stevens-tech.edu/~djd
313 Lieb Building		Voice: 201-216-5390
Stevens Institute of Technology	Fax: 201-216-8249
Castle Point on Hudson
Hoboken, NJ 07030





_______________________________________________
dcp mailing list
dcp@ietf.org
https://www1.ietf.org/mailman/listinfo/dcp