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

From: Dan Duchamp <[email-masked]>
Date: Mon, 8 Apr 2002 08:04:31 -0400

On Wed, 27 Mar 2002 [email-masked] 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: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dcp

---

From: Mark Handley <[email-masked]>
Date: Mon, 08 Apr 2002 09:49:45 -0700

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

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

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

>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

---

From: Aaron Falk <[email-masked]>
Date: 08 Apr 2002 10:00:04 -0700

On Mon, 2002-04-08 at 09:49, Mark Handley wrote:
> 
> If it would cause a problem that side A

This sounds like the kind of thing that should go into the
API/implementors advisory document we talked about.  Don't you think? 
Helping implementors do the right thing is important.

--aaron

---

From: Mark Handley <[email-masked]>
Date: Mon, 08 Apr 2002 10:14:04 -0700

>Helping implementors do the right thing is important.

Yes, definitely.  Probably quite a bit of our rationale should go
there - currently it's still in our heads, which probably isn't optimal.

Cheers,
	Mark

---

From: Aaron Falk <[email-masked]>
Date: 08 Apr 2002 10:22:46 -0700

On Mon, 2002-04-08 at 10:14, Mark Handley wrote:
>
>  currently it's still in our heads, which probably isn't optimal.

Until ITP (the Internet Telepathy Protocol) is finished, the
implementors will probably need some additional help. :)

--aaron

---

From: Eddie Kohler <[email-masked]>
Date: Mon, 08 Apr 2002 12:02:04 -0700

Some additions from my perspective:

> 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

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:

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

> feature negotiation that's looping.

The spec specifically allows this.

Eddie