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

[Eddie Kohler <kohler@icir.org>]

Some additions from my perspective:

> The intent is that you don't normally have to stop the connection
> while negotiation is happening.

The draft also says:

  In the Asking and Confirming states, the value of the corresponding feature
  is in flux. DCP MAY change its behavior in these states -- for example, by
  refusing to send data until reentering a Known state.

So your proposed simplification -- effectively stopping the connection in
order to do renegotiation, in that data is no longer sent by the
negotiating side -- is valid according to the specification. I sort of
thought that early implementations might do this for all negotiable
features, particularly CCID. (But excluding Ack Ratio, which is
non-negotiable.)

Nevertheless, it would be better to negotiate in parallel with the data
flow, even in early implementations. Take Mobility Capable, for example --
no reason to stop the data flow.

There is a conceptual difficulty here, in that any DCP connection can be in
multiple 'states' simultaneously, one 'state' per feature. Explicitly
representing those multiple states might be a good implementation choice.

> But what if 'Answer' is lost and DCP_A starts sending
> packets whose proper handling requires the new feature?

Now, DCP_B, in this case, _knows_ that the feature is in flux. After all,
it sent the Ask. So if it gets packets that it doesn't know how to
interpret, it is free to ignore them, or to save them for later (until it
gets an Answer). For instance, it might buffer the packets and report them
as 'not yet received' until it got an Answer, after which it would report
them as Received/ECN marked, as appropriate.

Therefore, I'm not sure I agree with this statement of Mark's:

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

It's worth considering, but not a showstopper for any feature. And I think
it might be better overall if DCP implementations contained a
general-purpose mechanism for dealing with feature negotiation, like
delaying packets, rather than relying on N feature-specific mechanisms.
Feature-specific mechanisms are icing on the cake.

Another note:

> It's clear that implementations would normally decide to terminate a
> feature negotiation that's looping.

The spec specifically allows this.

Eddie

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