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

[Mark Handley <mjh@icir.org>]

>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.

The intent is that you don't normally have to stop the connection
while negotiation is happening.  This is especially true with
ACK-Ratio, where you definitely don't want to stop the connection.
But it should be true for all the features we've currently got
specified.  

It's possible that some future features would require pausing the data
flow, because it wasn't safe to continue, but:

 - we don't know what those features would be right now.
 - we must assume a DCP implementation that implements such features
   would know to pause the data flow.

>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?

The answer can indeed be lost.  Subsequent packets from the Asker will
repeat the Ask until some form of answer is given, so the negotiation
is ultimately reliable.

No packet based communication that doesn't have synchonized clocks can
reliably ensure that both sides switch at the same time.  This is the
well-known last-ACK problem.  If it would cause a problem that side A
starts using a feature that the side B has requested before the answer
reaches side B, then it is necessary for that feature to be
self-explanatory from the data packets.  This is not the case for
features such as ACK-ratio, but it is something that feature designers
need to think about.

>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?

Yes, thanks for pointing this out.  We changed the option type code
numbers, but missed this example.

>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?

No, on both points.

It's clear that implementations would normally decide to terminate a
feature negotiation that's looping.  But we don't know in advance how
long the longest possible reasonable negotiation process might be.
Also it's not possible to decide the correct course of action for all
future features - for some it may be important that the negotiation
succeeds and we want to termimate the connection if it fails.  For
others it may only be desirable, but not a showstopper.  Thus how to
determine that an option negotiation is not going to terminate is
really an implementation issue, and what to do when option negotiation
doesn't succeed is really a feature-specific issue.

For congestion control, note that DCP MUST choose a congestion control
scheme before sending data packets, and so failed agreement to changes
in congestion control scheme are not a serious problem as there's
already a valid scheme in use.

Cheers,
	Mark

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