From daemon@ns.ietf.org Mon Apr 8 08:04:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21057 for ; Mon, 8 Apr 2002 08:04:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00016 for dcp-archive@odin.ietf.org; Mon, 8 Apr 2002 08:04:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00007; Mon, 8 Apr 2002 08:04:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29972 for ; Mon, 8 Apr 2002 08:04:39 -0400 (EDT) Received: from guinness.cs.stevens-tech.edu (guinness.cs.stevens-tech.edu [155.246.89.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21051 for ; Mon, 8 Apr 2002 08:04:35 -0400 (EDT) Received: by guinness.cs.stevens-tech.edu (Postfix, from userid 3718) id B6EDB143967; Mon, 8 Apr 2002 08:04:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by guinness.cs.stevens-tech.edu (Postfix) with ESMTP id A7608C47A0; Mon, 8 Apr 2002 08:04:31 -0400 (EDT) Date: Mon, 8 Apr 2002 08:04:31 -0400 From: Dan Duchamp To: dcp@ietf.org Cc: Marek Zawadzki In-Reply-To: <200203271744.MAA20897@optimus.ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dcp] Re: dcp digest, Vol 1 #18 - 1 msg Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org 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 From daemon@ns.ietf.org Mon Apr 8 12:51:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29629 for ; Mon, 8 Apr 2002 12:51:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21396 for dcp-archive@odin.ietf.org; Mon, 8 Apr 2002 12:51:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21283; Mon, 8 Apr 2002 12:49:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21236 for ; Mon, 8 Apr 2002 12:49:55 -0400 (EDT) Received: from aardvark.icir.org (aardvark.icir.org [192.150.187.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29612 for ; Mon, 8 Apr 2002 12:49:52 -0400 (EDT) Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.11.6/8.11.3) with ESMTP id g38Gnjk15655; Mon, 8 Apr 2002 09:49:45 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Dan Duchamp cc: dcp@ietf.org, Marek Zawadzki Subject: Re: [dcp] Re: dcp digest, Vol 1 #18 - 1 msg In-reply-to: Your message of "Mon, 08 Apr 2002 08:04:31 EDT." Date: Mon, 08 Apr 2002 09:49:45 -0700 Message-ID: <15653.1018284585@aardvark.icir.org> Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.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 From daemon@ns.ietf.org Mon Apr 8 13:00:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29828 for ; Mon, 8 Apr 2002 13:00:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21764 for dcp-archive@odin.ietf.org; Mon, 8 Apr 2002 13:00:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21723; Mon, 8 Apr 2002 13:00:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21688 for ; Mon, 8 Apr 2002 13:00:06 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29808 for ; Mon, 8 Apr 2002 13:00:03 -0400 (EDT) Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g38H04T01507; Mon, 8 Apr 2002 10:00:04 -0700 (PDT) Subject: Re: [dcp] Re: dcp digest, Vol 1 #18 - 1 msg From: Aaron Falk To: Mark Handley Cc: dcp@ietf.org In-Reply-To: <15653.1018284585@aardvark.icir.org> References: <15653.1018284585@aardvark.icir.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 08 Apr 2002 10:00:04 -0700 Message-Id: <1018285204.28848.17.camel@nit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2002-04-08 at 09:49, Mark Handley wrote: > > 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. > 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 _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Mon Apr 8 13:14:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00173 for ; Mon, 8 Apr 2002 13:14:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22823 for dcp-archive@odin.ietf.org; Mon, 8 Apr 2002 13:14:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22814; Mon, 8 Apr 2002 13:14:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22779 for ; Mon, 8 Apr 2002 13:14:06 -0400 (EDT) Received: from aardvark.icir.org (aardvark.icir.org [192.150.187.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00167 for ; Mon, 8 Apr 2002 13:14:03 -0400 (EDT) Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.11.6/8.11.3) with ESMTP id g38HE4k15811; Mon, 8 Apr 2002 10:14:04 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Aaron Falk cc: dcp@ietf.org Subject: Re: [dcp] Re: dcp digest, Vol 1 #18 - 1 msg In-reply-to: Your message of "08 Apr 2002 10:00:04 PDT." <1018285204.28848.17.camel@nit> Date: Mon, 08 Apr 2002 10:14:04 -0700 Message-ID: <15809.1018286044@aardvark.icir.org> Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org >On Mon, 2002-04-08 at 09:49, Mark Handley wrote: >> >> 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. >> > >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. 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 _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Mon Apr 8 13:22:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00346 for ; Mon, 8 Apr 2002 13:22:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23098 for dcp-archive@odin.ietf.org; Mon, 8 Apr 2002 13:22:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23086; Mon, 8 Apr 2002 13:22:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23052 for ; Mon, 8 Apr 2002 13:22:48 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00341 for ; Mon, 8 Apr 2002 13:22:45 -0400 (EDT) Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g38HMkT16004; Mon, 8 Apr 2002 10:22:46 -0700 (PDT) Subject: Re: [dcp] Re: dcp digest, Vol 1 #18 - 1 msg From: Aaron Falk To: Mark Handley Cc: dcp@ietf.org In-Reply-To: <15809.1018286044@aardvark.icir.org> References: <15809.1018286044@aardvark.icir.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 08 Apr 2002 10:22:46 -0700 Message-Id: <1018286566.28848.21.camel@nit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Content-Transfer-Encoding: 7bit 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 _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Mon Apr 8 15:03:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02962 for ; Mon, 8 Apr 2002 15:03:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00601 for dcp-archive@odin.ietf.org; Mon, 8 Apr 2002 15:03:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00529; Mon, 8 Apr 2002 15:02:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00492 for ; Mon, 8 Apr 2002 15:02:12 -0400 (EDT) Received: from coyote.icir.org (coyote.icir.org [192.150.187.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02901 for ; Mon, 8 Apr 2002 15:02:09 -0400 (EDT) Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.11.6/8.11.3) with ESMTP id g38J24608999; Mon, 8 Apr 2002 12:02:04 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200204081902.g38J24608999@coyote.icir.org> To: Dan Duchamp , dcp@ietf.org, Marek Zawadzki Subject: Re: [dcp] Re: dcp digest, Vol 1 #18 - 1 msg In-Reply-To: Message from Mark Handley of "Mon, 08 Apr 2002 09:49:45 PDT." <15653.1018284585@aardvark.icir.org> Date: Mon, 08 Apr 2002 12:02:04 -0700 From: Eddie Kohler Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.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 From daemon@ns.ietf.org Tue Apr 16 02:12:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24020 for ; Tue, 16 Apr 2002 02:12:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20993 for dcp-archive@odin.ietf.org; Tue, 16 Apr 2002 02:12:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20981; Tue, 16 Apr 2002 02:12:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20946 for ; Tue, 16 Apr 2002 02:12:10 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23935 for ; Tue, 16 Apr 2002 02:12:06 -0400 (EDT) Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3G6C43G008795 for ; Tue, 16 Apr 2002 08:12:04 +0200 (MEST) Received: by lms001.lu.erisoft.se id IAA24192; Tue, 16 Apr 2002 08:12:03 +0200 (MET DST) Message-ID: <3CBBC0B3.AD6117F2@epl.ericsson.se> Date: Tue, 16 Apr 2002 08:12:03 +0200 From: Sara Karlberg Organization: Ericsson Erisoft AB X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: dcp@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dcp] Features Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a little example; -Imagine that you want to use CCID 2 hence you start to negotiate the use of Ack Vector with the DCP-Response packet. -Instead of using CCID 2 you settle on using CCID 3 after negotiating with the other end. -Then you will have to reopen the Ack Vector negotiation if you only want the Ack Vector option to be used in combination with CCID 2 not with CCID3. Consider a large number of such dependencies where the use of one feature depends on another feature being used. It could take several rounds before you have achieved the desired settings making it difficult to know how to properly handle data. One way to remove some negotiations would be to make it unnecessary to establish the value of features which are mandatory for a particular CCID through negotiation, let them be determined by the CCID instead. Such an example would be the Ack Vector for CCID2. When you have opted for CCID2, the Ack Vector could be included automatically. A related question is which end-point should have the most influence on the decision taken (mainly CCID)? The sender knows more about the data to be sent (probably only after the application request though). However, the receiver might be asked to hold a lot of state, send data and it sees the final result ... so it needs to have some saying. When studying the drafts I get a feeling that it is possible to manipulate the negotiation to get it where you want depending on the implementation. Are you planning on enforcing a certain behavior so that one end-point has more influence? I have another issue which I would only like confirmed; at connection set-up is it enough to agree on the CCID to start sending data, the rest of the negotiations can be concluded while sending data? Please correct me if I am wrong about something. Thank you, Sara _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Tue Apr 16 12:44:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17359 for ; Tue, 16 Apr 2002 12:44:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28477 for dcp-archive@odin.ietf.org; Tue, 16 Apr 2002 12:44:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28470; Tue, 16 Apr 2002 12:44:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28437 for ; Tue, 16 Apr 2002 12:44:06 -0400 (EDT) Received: from coyote.icir.org (coyote.icir.org [192.150.187.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17319 for ; Tue, 16 Apr 2002 12:44:02 -0400 (EDT) Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.11.6/8.11.3) with ESMTP id g3GGi1672844; Tue, 16 Apr 2002 09:44:01 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200204161644.g3GGi1672844@coyote.icir.org> To: Sara Karlberg cc: dcp@ietf.org Subject: Re: [dcp] Features In-Reply-To: Message from Sara Karlberg of "Tue, 16 Apr 2002 08:12:03 +0200." <3CBBC0B3.AD6117F2@epl.ericsson.se> Date: Tue, 16 Apr 2002 09:44:01 -0700 From: Eddie Kohler Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Hi Sara, my take: > One way to remove some negotiations would be to make it unnecessary to > establish the value of features which are mandatory for a particular > CCID through negotiation, let them be determined by the CCID instead. > Such an example would be the Ack Vector for CCID2. When you have opted > for CCID2, the Ack Vector could be included automatically. You are right that several negotiations might be required, although they could be largely overlapped, but I bet this won't happen very often. For instance, the usual sequence for a server S choosing CCID 2 would look like this: C->S: Ask CC 2 S->C: Answer CC 2; Ask Use Ack Vector 1 C->S: Answer Use Ack Vector 1 Note that Use Ack Vector isn't negotiated until the end. S asks the client C to use the Ack Vector, so that request can piggyback on the Answer. We negotiate the features independently from CCID to facilitate extensibility. This way, a new CCID can be deployed without upgrading every DCP implementation in the world; it'll request the features it needs. Your solution would certainly help if long negotiations became a problem in practice. > Are you planning on enforcing a certain > behavior > so that one end-point has more influence? We weren't planning on it. CCID negotiation is a negotiation among equal parties. > I have another issue which I would only like confirmed; at connection > set-up is it enough to agree on the CCID to start sending data, the rest > of the negotiations can be concluded while sending data? You're right. To clarify, though: The draft says you cannot send data when you don't have a valid CCID. An implementation, or a particular CCID, might further hold off until some additional features are negotiated. That would depend on the implementation and the features. For example, CCID 2 might refuse to send data (or more than an initial window of data) until the receiver agrees to Use Ack Vector. Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Wed Apr 17 09:56:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17952 for ; Wed, 17 Apr 2002 09:56:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10875 for dcp-archive@odin.ietf.org; Wed, 17 Apr 2002 09:56:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10861; Wed, 17 Apr 2002 09:56:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10819 for ; Wed, 17 Apr 2002 09:56:09 -0400 (EDT) Received: from nexus.stwing.upenn.edu (NEXUS.STWING.UPENN.EDU [165.123.132.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17903 for ; Wed, 17 Apr 2002 09:56:05 -0400 (EDT) Received: from waltsony (dhcp0283.grt.resnet.group.upenn.edu [165.123.141.167]) (authenticated (0 bits)) by nexus.stwing.upenn.edu (8.11.6/8.11.6) with ESMTP id g3HDu7m04083 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 17 Apr 2002 09:56:07 -0400 (EDT) Reply-To: From: "Walter R. Rice" To: Date: Wed, 17 Apr 2002 09:56:06 -0400 Message-ID: <003f01c1e617$9f8822e0$a78d7ba5@waltsony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [dcp] DCP and IPv6? Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Content-Transfer-Encoding: 7bit Hello, Has there been any consideration as to how DCP will function in an IPv6 environment; specifically if any of its features would no longer be relevant, or would break? Thanks, Walter Rice ricew@stwing.upenn.edu _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Wed Apr 17 15:31:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03275 for ; Wed, 17 Apr 2002 15:31:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10866 for dcp-archive@odin.ietf.org; Wed, 17 Apr 2002 15:31:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10720; Wed, 17 Apr 2002 15:31:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10675 for ; Wed, 17 Apr 2002 15:31:00 -0400 (EDT) Received: from book.ducksong.com (pool-141-154-200-65.bos.east.verizon.net [141.154.200.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03242 for ; Wed, 17 Apr 2002 15:30:56 -0400 (EDT) Received: (from mcmanus@localhost) by book.ducksong.com (8.11.6/8.11.6) id g3HJWOE01482 for dcp@ietf.org; Wed, 17 Apr 2002 15:32:24 -0400 Date: Wed, 17 Apr 2002 15:32:24 -0400 From: "Patrick R. McManus" To: dcp@ietf.org Message-ID: <20020417193224.GA1460@ducksong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [dcp] Comments and Question Re: DCP drafts Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Hi All, I've read through the dcp drafts (dcp-02, ccids, and the problem document) and have a collection of questions, observations, and editorial comments to make. First, the easy stuff (editorial comments): p 14, # NDP - "A non-data packet is simply any packet not containing user data; Data-Ack packets are the canonical example." I believe this should be "DCP-Ack packets are the canonical example." p 7, sec 3.3 - "reasonable time, allowing old segments to clear".. this is the only time in the document that the word segment occurs. DCP lingo seems to be packet (else segment needs to be defined). ----- observation - acks of acks are a pretty non-intuitive concept if you're starting with TCP as your knowledge base (likely the case if people use the rfc to implement the protocol). While reading the drafts I wondered for a very long time if an established DCP session under CCID 2 could ever go totally idle - or if the hosts would have to be sending dcp-ack back and forth every rtt. I now understand why this is not so, but the heavy dusting of "acks for acks" language throughout the document before discussion of this at the very end was the most confusing part of a document that, overall, was very clear and useful. There are a number of references to "at least one ack per round trip time" that can imply this case for the sloppy (or perhaps just first-time) reader (aka me). It became clear for me in section 4.3 of the ccid2 document, after I'd read the whole dcp doc as well. My a-ha moment was realizing that the purpose of acking an ack was to shrink a stored ack vector state - and if the sender was quiet then the corresponding vector couldn't be growing and therefore doesn't really need to be shrunk. Perhaps some high level discussion of the way acks differ from dhcp needs to make it earlier in the document - my first question mark appeared in section 4.1.1 where it said "Some of these data packets are DCP-DataAck packets acknowledging data and/or ack packets from the client.", and there were many more big question marks in the margin before it sunk in. -- observation 2 - I like the service name addition to the rcp-request packet. This greatly expands the namespace at a well known service point. -- observation 3 - This is really an API comment, and I know dealing with API issues is tricky and/or inappropriate - but I think this comment can be dealt with in the sense that the PMTU section does. Its going to take me a couple paragraphs to get to my point. It seems obvious to me that one API for DCP looks a lot like UDP.. socket(AF_INET, SOCK_DCP, 0), recv(), send(), setsockopt(), close(), etc.. This is particularly impt for 'reluctant applications' currently using udp but not using cong control. one of the reasons that apps avoid tcp today is its in-order property wherein a sequence of 1,2,4 that is recvd will only give the application pkts 1 and 2 until 3 is obtained. By the time 3 arrives 4 may have lost its value alltogether. DCP solves that nicely. However, if cwnd is limiting the sending rate a similar q'ing problem can result inside the dcp-sender's buffer. If the sender is only able to trickle data out - the application may wish to throw away pending data and just move on to more current stuff. I mention this because when programming with UDP you don't really consider the case of send() to be signifcantly delayed at your host. Creating a large q of data (where you had been counting on a fraction of those packets to be dropped due to congestion you induced!) could be a real problem. Under UDP the message might be dropped, but not delayed beyond the needs of the transmission medium. So this could really inhibit porting of applications that just blast N kbit/s of data, expecting the bottleneck bandwidth to get through and the backlog to simply be dropped as you go along. A setsockopt() that causes send() to fail or block (or one for each!) if new writes would be delayed by the ccid would seem to be critical to porting current UDP based programs. Providing a mechanism to determine if writes would be delayed by a cc policy could be a MUST in the same sense that section 10 makes it a MUST to "allow the application to discover DCP's current PMTU" ----- question - for experimentation purposes is this envisioned as being built on top of udp, IP, or ???? - has a convention been established for port numbers or protocol numbers? -Patrick _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Thu Apr 18 07:59:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01776 for ; Thu, 18 Apr 2002 07:59:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19693 for dcp-archive@odin.ietf.org; Thu, 18 Apr 2002 07:59:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19652; Thu, 18 Apr 2002 07:58:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19620 for ; Thu, 18 Apr 2002 07:58:15 -0400 (EDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01770 for ; Thu, 18 Apr 2002 07:58:11 -0400 (EDT) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA11986; Thu, 18 Apr 2002 12:57:36 +0100 (BST) Date: Thu, 18 Apr 2002 12:57:36 +0100 From: Derek Fawcus To: "Walter R. Rice" Cc: dcp@ietf.org Subject: Re: [dcp] DCP and IPv6? Message-ID: <20020418125736.A9497@edinburgh.cisco.com> References: <003f01c1e617$9f8822e0$a78d7ba5@waltsony> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <003f01c1e617$9f8822e0$a78d7ba5@waltsony>; from ricew@stwing.upenn.edu on Wed, Apr 17, 2002 at 09:56:06AM -0400 Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org On Wed, Apr 17, 2002 at 09:56:06AM -0400, Walter R. Rice wrote: > > Hello, > > Has there been any consideration as to how DCP will function in an IPv6 > environment; specifically if any of its features would no longer be > relevant, or would break? Yeah - The header checksum is inappropriate. At the moment it appears that the checksum is just over the DCP data, and does not include any pseudo header. Given the lack of an IP header checksum in IPv6, the DCP header checksum should really be calculated in a similar fashion to the TCP/UDP header checksum - including a psuedo header. So for IPv6 the header pseudo header should be as shown in section 8.1 of RFC 2460. The mobility part of the DCP draft obviously won't work ggiven that it embeds an IPv4 address. DF _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Wed Apr 24 04:14:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27193 for ; Wed, 24 Apr 2002 04:14:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12101 for dcp-archive@odin.ietf.org; Wed, 24 Apr 2002 04:14:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12064; Wed, 24 Apr 2002 04:14:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12027 for ; Wed, 24 Apr 2002 04:14:15 -0400 (EDT) Received: from US0.pxxserver.com ([202.58.246.74]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27177 for ; Wed, 24 Apr 2002 04:14:03 -0400 (EDT) Received: from localhost ([202.58.246.74]) by US0.pxxserver.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Apr 2002 17:22:42 +0800 X-Sender: vdlynros@yahoo.com From: Videlyn To: dcp@ietf.org Date: Wed, 24 Apr 2002 17:22:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 24 Apr 2002 09:22:42.0030 (UTC) FILETIME=[95CF30E0:01C1EB71] Content-Transfer-Encoding: 7bit Subject: [dcp] E-business Learning While Earning Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Content-Transfer-Encoding: 7bit Hello, Greetings! I am Videlyn Jones. I am a successful student of an online e-business institute, earning income for working only a few hours a day by applying what I have learned from the institute. If you like to learn e-business program while earning a residual income, I can give you a FREE membership ID. Just reply to vdlynros@yahoo.com and put "Send Me Free ID" in the subject with your full name as the content of the mail. You can also use your ID# to avail big discounts. You can earn a full monthly income or even more while learning in your convenient time and place, like at home. You will be working with a team that will teach you the easiest way to do the work, and not send auto-responders. Regards Videlyn Note: You don't need to request for removal. This is a one-time email. Your email address will be automatically removed in our list if you don't reply in this mail. _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Thu Apr 25 21:47:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11889 for ; Thu, 25 Apr 2002 21:47:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA25245 for dcp-archive@odin.ietf.org; Thu, 25 Apr 2002 21:47:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25234; Thu, 25 Apr 2002 21:47:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25205 for ; Thu, 25 Apr 2002 21:47:50 -0400 (EDT) Received: from coyote.icir.org (coyote.icir.org [192.150.187.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11875 for ; Thu, 25 Apr 2002 21:43:30 -0400 (EDT) Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.11.6/8.11.3) with ESMTP id g3Q1gA697341; Thu, 25 Apr 2002 18:42:11 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200204260142.g3Q1gA697341@coyote.icir.org> To: "Patrick R. McManus" cc: dcp@ietf.org Subject: Re: [dcp] Comments and Question Re: DCP drafts In-Reply-To: Message from "Patrick R. McManus" of "Wed, 17 Apr 2002 15:32:24 EDT." <20020417193224.GA1460@ducksong.com> Date: Thu, 25 Apr 2002 18:42:10 -0700 From: Eddie Kohler Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Hi Patrick, thanks very much for your comments! > observation - acks of acks are a pretty non-intuitive concept if > you're starting with TCP as your knowledge base ... Totally fair observation. I've rewritten the most relevant section of the DCCP draft; it's included below. Let us know if that helps. > observation 3 - This is really an API comment, and I know dealing with > API issues is tricky and/or inappropriate - ... Another fair observation, and not inappropriate at all. We are concerned about balancing the needs for kernel buffering, to achieve reasonable utilization, and responsive feedback, so old useless data doesn't get sent. We're considering a mechanism like the sockopt() you suggest, as well as other mechanisms, including maybe a callback design. > question - for experimentation purposes is this envisioned as being > built on top of udp, IP, or ???? - has a convention been established > for port numbers or protocol numbers? We're envisioning it as on top of IP, parallel with UDP, although of course layering over UDP is possible for experiments. As far as numbers go, Jon Crowcroft kindly 'lent' the IP protocol number 33 to us for experimentation. Eddie 7.1. Acks of Acks and Unidirectional Connections DCCP was designed to work well for both bidirectional and unidirectional flows of data, and for connections that transition between these states. However, acknowledgements required for a unidirectional connection are very different from those required for a bidirectional connection. In particular, unidirectional connections need to worry about acks of acks. The ack-of-acks problem arises because some acknowledgement mechanisms are reliable. For example, an HC-Receiver using CCID 2, TCP-like Congestion Control, sends Ack Vectors containing completely reliable acknowledgement information. The HC-Sender should occasionally inform the HC-Receiver that it has received an ack. If it did not, the HC-Receiver might resend complete Ack Vector information, going back to the start of the connection, with every DCCP-Ack packet! However, note that acks-of-acks need not be reliable themselves: when an ack-of-acks is lost, the HC-Receiver will simply maintain old acknowledgement-related state for a little longer. Therefore, there is no need for acks of acks of acks. When communication is bidirectional, any required acks of acks are automatically contained in normal acknowledgements for data packets. On a unidirectional connection, however, the receiver DCCP sends no data, so the sender would not normally send acknowledgements. Therefore, the CCID in force on that half-connection must explicitly say whether, when, and how the HC-Sender should generate acks of acks. For example, consider a bidirectional connection where both half- connections use the same CCID (either 2 or 3), and where DCCP B goes *quiescent*. This means that the connection becomes unidirectional: DCCP B stops sending data, and sends only sends DCCP-Ack packets to DCCP A. For CCID 2, TCP-like Congestion Control, DCCP B uses Ack Vector to reliably communicate which packets it has received. As described above, DCCP A must occasionally acknowledge a pure acknowledgement from DCCP B, so that DCCP B can free old Ack Vector state. For instance, DCCP A might send a DCCP-DataAck packet every now and then, instead of DCCP-Data. In contrast, for CCID 3, TFRC Congestion Control, DCCP B's acknowledgements need not be reliable, since they contain cumulative loss rates; TFRC works even if every DCCP-Ack is lost. Therefore, DCCP A need never acknowledge an acknowledgement. When communication is unidirectional, a single CCID---in the example, the A-to-B CCID---controls both DCCPs' acknowledgements, in terms of their content, their frequency, and so forth. For bidirectional connections, the A-to-B CCID governs DCCP B's acknowledgements (including its acks of DCCP A's acks), while the B- to-A CCID governs DCCP A's acknowledgements. DCCP A switches its ack pattern from bidirectional to unidirectional when it notices that DCCP B has gone quiescent. It switches from unidirectional to bidirectional when it must acknowledge even a single DCCP-Data or DCCP-DataAck packet from DCCP B. (This includes the case where a single DCCP-Data or DCCP-DataAck packet was lost in transit, which is detectable using the # NDP field in the DCCP packet header.) Each CCID defines how to detect quiescence on that CCID, and how that CCID handles acks-of-acks on unidirectional connections. The B- to-A CCID defines when DCCP B has gone quiescent. Usually, this happens when a period (for CCID 2, roughly two round-trip times) has passed without B sending any data packets. The A-to-B CCID defines how DCCP A handles acks-of-acks once DCCP B has gone quiescent. _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Fri Apr 26 18:52:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23695 for ; Fri, 26 Apr 2002 18:52:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29180 for dcp-archive@odin.ietf.org; Fri, 26 Apr 2002 18:53:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29171; Fri, 26 Apr 2002 18:52:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29136 for ; Fri, 26 Apr 2002 18:52:43 -0400 (EDT) Received: from coyote.icir.org (coyote.icir.org [192.150.187.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23640 for ; Fri, 26 Apr 2002 18:52:37 -0400 (EDT) Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.11.6/8.11.3) with ESMTP id g3QMo2606278; Fri, 26 Apr 2002 15:50:02 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200204262250.g3QMo2606278@coyote.icir.org> To: Derek Fawcus cc: "Walter R. Rice" , dcp@ietf.org Subject: Re: [dcp] DCP and IPv6? In-Reply-To: Message from Derek Fawcus of "Thu, 18 Apr 2002 12:57:36 BST." <20020418125736.A9497@edinburgh.cisco.com> Date: Fri, 26 Apr 2002 15:50:02 -0700 From: Eddie Kohler Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Hey Derek, > At the moment it appears that the checksum is just over the DCP data, > and does not include any pseudo header. Given the lack of an IP header > checksum in IPv6, the DCP header checksum should really be calculated > in a similar fashion to the TCP/UDP header checksum - including a psuedo > header. So for IPv6 the header pseudo header should be as shown in > section 8.1 of RFC 2460. > > The mobility part of the DCP draft obviously won't work ggiven that it > embeds an IPv4 address. Thanks for pointing out these issues! We've modified the draft to (a) include a network-level pseudoheader in the DCCP checksum calculation, and (b) embed an Address Family number in the DCCP-Move packet, with Old Address taking that family, so that the packet supports both IPv4 and IPv6. Anybody think of any other DCCP-IPv6 issues? Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Fri Apr 26 20:53:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06175 for ; Fri, 26 Apr 2002 20:53:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04356 for dcp-archive@odin.ietf.org; Fri, 26 Apr 2002 20:53:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04349; Fri, 26 Apr 2002 20:53:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04314 for ; Fri, 26 Apr 2002 20:53:29 -0400 (EDT) Received: from coyote.icir.org (coyote.icir.org [192.150.187.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06142 for ; Fri, 26 Apr 2002 20:53:25 -0400 (EDT) Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.11.6/8.11.3) with ESMTP id g3R0rR607036 for ; Fri, 26 Apr 2002 17:53:27 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200204270053.g3R0rR607036@coyote.icir.org> To: dcp@ietf.org Subject: Re: [dcp] DCP and IPv6? Date: Fri, 26 Apr 2002 17:53:27 -0700 From: Eddie Kohler Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org FYI, from a message to Armando Caro: > I have to be honest and say that have followed the DCP work VERY closely, > but I am curious... when did the name change to DDCP? and what does it > stand for? At the IETF in Salt Lake, there were strong objections to the name DCP (Datagram Control Protocol), because the acronym sounded so much like TCP. Lazy enunciators, all of them, but the current choice is DCCP (Datagram Congestion Control Protocol). Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Mon Apr 29 06:38:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20489 for ; Mon, 29 Apr 2002 06:38:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11296 for dcp-archive@odin.ietf.org; Mon, 29 Apr 2002 06:38:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11280; Mon, 29 Apr 2002 06:38:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11249 for ; Mon, 29 Apr 2002 06:38:17 -0400 (EDT) Received: from pif.inria.fr (IDENT:root@pif.inria.fr [138.96.88.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20484 for ; Mon, 29 Apr 2002 06:38:15 -0400 (EDT) Received: from pif.inria.fr by pif.inria.fr (8.11.6/8.11.6) with ESMTP id g3TAcGd05948 for ; Mon, 29 Apr 2002 12:38:16 +0200 Message-Id: <200204291038.g3TAcGd05948@pif.inria.fr> X-Mailer: exmh version 2.5 07/13/2001 To: dcp@ietf.org X-Face: #vC:Fjgsq2zTq\Je)y)!|n$C}&y*15D#EsD#s6]0hMh-`9!|7]P[*BRry&BY{31Kzr Subject: [dcp] is ...ticast taboo ? Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Hi all, Even if multicast congestion control is not as mature than unicast congestion control, I'm not sure it is a good idea to prevent future possible extensions of DCP for multicast. For example the concept of connections with mandatory acknowledgments, reliable handshakes, etc. could be mandatory for unicast flows and optional (for small groups) or forbidden for multicast flows. A simple scheme without negotiation for multicast is when the source selects the congestion control to be used for all receivers. Is it the moment to forecast such extensions in the draft, or just open a door? Cheers Thierry _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Mon Apr 29 14:34:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10481 for ; Mon, 29 Apr 2002 14:34:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11845 for dcp-archive@odin.ietf.org; Mon, 29 Apr 2002 14:34:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11836; Mon, 29 Apr 2002 14:34:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11801 for ; Mon, 29 Apr 2002 14:34:50 -0400 (EDT) Received: from coyote.icir.org (coyote.icir.org [192.150.187.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10475 for ; Mon, 29 Apr 2002 14:34:45 -0400 (EDT) Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.11.6/8.11.3) with ESMTP id g3TIYi630208; Mon, 29 Apr 2002 11:34:44 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200204291834.g3TIYi630208@coyote.icir.org> To: Thierry Turletti cc: dcp@ietf.org Reply-To: dcp@ietf.org Subject: Re: [dcp] is ...ticast taboo ? In-Reply-To: Message from Thierry Turletti of "Mon, 29 Apr 2002 12:38:16 +0200." <200204291038.g3TAcGd05948@pif.inria.fr> Date: Mon, 29 Apr 2002 11:34:44 -0700 From: Eddie Kohler Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Hi Thierry, Our take is that we designed DCCP for unicast, and the vast majority of its features (acks, feature negotiation, ...) would not be meaningful in a multicast context. Any DCCP-like protocol for multicast would be so different that you might as well give it its own name. Of course such a protocol could use ideas from DCCP, as far as they are applicable. Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Mon Apr 29 16:10:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17898 for ; Mon, 29 Apr 2002 16:10:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17834 for dcp-archive@odin.ietf.org; Mon, 29 Apr 2002 16:10:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17708; Mon, 29 Apr 2002 16:09:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17662 for ; Mon, 29 Apr 2002 16:09:35 -0400 (EDT) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17845 for ; Mon, 29 Apr 2002 16:09:32 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g3TK9Wq26047; Mon, 29 Apr 2002 16:09:33 -0400 Message-Id: <200204292009.g3TK9Wq26047@minotaur.nge.isi.edu> To: Thierry Turletti CC: dcp@ietf.org Reply-To: mankin@isi.edu Subject: Re: [dcp] is ...ticast taboo ? In-reply-to: Your message of Mon, 29 Apr 2002 11:34:44 -0700. <200204291834.g3TIYi630208@coyote.icir.org> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Mon, 29 Apr 2002 16:09:32 -0400 From: Allison Mankin Sender: dcp-admin@ietf.org Errors-To: dcp-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Datagram Control Protocol X-BeenThere: dcp@ietf.org Another reply is that protocols being developed in the RMT working group have congestion control building blocks and have a range of "reliability". They may well provide whatever DCCP-like protocol you might envision for multicast... Allison _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp