From daemon@optimus.ietf.org Sat May 4 07:53: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 HAA22856 for ; Sat, 4 May 2002 07:53:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16507 for dcp-archive@odin.ietf.org; Sat, 4 May 2002 07:53: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 HAA16494; Sat, 4 May 2002 07:53: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 HAA16465 for ; Sat, 4 May 2002 07:53:49 -0400 (EDT) Received: from galactica.firstbangla.com ([203.82.193.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22849 for ; Sat, 4 May 2002 07:53:33 -0400 (EDT) Date: Sat, 4 May 2002 17:57:37 +0600 Message-ID: <1A9272A914751640B9FA74C59F890A180150FA@galactica.firstbangla.com> Thread-Topic: dcp implementation.... MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F362.E290B144" Thread-Index: AcHzYuJiwrmpPn8TT4iE4crM5OF2EA== X-Priority: 1 Priority: Urgent Importance: high content-class: urn:content-classes:message From: "Asif Rahim" To: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: [dcp] dcp implementation.... 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C1F362.E290B144 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello. We're very eager to know about the advantages of DCP over TCP/UDP. Is there an implementation available??? We'd like to see that and test your new protocol in our labs. Thanks. - Asif. North South University Dhaka, Bangladesh. ------_=_NextPart_001_01C1F362.E290B144 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello.

We’re very eager to know about the advantages = of DCP over TCP/UDP.

Is there an implementation = available???

We’d like to see that and test your new = protocol in our labs.

Thanks.

- Asif.

North = South = University

Dhaka, = Bangladesh.

=00 ------_=_NextPart_001_01C1F362.E290B144-- _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Sat May 4 12:29:17 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 MAA26475 for ; Sat, 4 May 2002 12:29:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27034 for dcp-archive@odin.ietf.org; Sat, 4 May 2002 12:29:23 -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 MAA26990; Sat, 4 May 2002 12:28:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26955 for ; Sat, 4 May 2002 12:28:09 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26412 for ; Sat, 4 May 2002 12:28:01 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g44GSQn25817 for ; Sat, 4 May 2002 19:28:27 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 4 May 2002 19:28:04 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 4 May 2002 19:28:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 4 May 2002 19:28:05 +0300 Message-ID: <58AEDE27D48F884285007ABF827FF26346A3E6@esebe017.NOE.Nokia.com> Thread-Topic: DCP comment Thread-Index: AcHzcwe3S0rkKV6WEdatlwCQJ3jjygAFXYpw To: X-OriginalArrivalTime: 04 May 2002 16:28:05.0943 (UTC) FILETIME=[AB60BC70:01C1F388] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA26956 Subject: [dcp] DCP comment: Support for 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: 8bit Hi all! I have taken a look to the DCP draft, and I was so surprised when I saw that the DCP-Move Packet has the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Generic DCP Header / / (12 octets) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Acknowledgement Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old Port | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobility Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Obviously, there is no support for IPv6 addresses... I know that the support for mobility that DCP offers is very limited, and that it is the intention of the authors to keep DCP as simple as possible. However, wouldn't it be better something like this? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Generic DCP Header / / (12 octets) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Acknowledgement Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old Port | Old IP Address Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Old IP Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobility Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And then making the "Old IP Address" a 4-byte or 16-byte long field. Since this kind of packet is not supposed to be a common one, you can always use always a 16-byte long field and then use only the first 4 bytes if the old address was an IPv4. For the "Old IP Address Type", you can use the types 4 or 6 for IPv4 and IPv6 (or 5 and 6 as done in SCTP, :->), or simply 4 and 16 (and then call this field "Old IP Address Length"), so the calculation of the position is easier to do... Instead of using the second 16-bit Reserved field, you could use the first one. Or use only one byte of that second Reserved field, so you still have space to include more fields in the future... In my opinion, giving support only for IPv4 is somehow shortsighted... :-/. Note than I'm not an expert at all in DCP and I might be saying something silly. Thanks! BR Iván Arias Rodríguez _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Sat May 4 13:10:35 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 NAA27048 for ; Sat, 4 May 2002 13:10:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28751 for dcp-archive@odin.ietf.org; Sat, 4 May 2002 13:10:38 -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 NAA28744; Sat, 4 May 2002 13:10:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28707 for ; Sat, 4 May 2002 13:10:33 -0400 (EDT) Received: from book.ducksong.com (pool-141-154-200-190.bos.east.verizon.net [141.154.200.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27043 for ; Sat, 4 May 2002 13:10:28 -0400 (EDT) Received: (from mcmanus@localhost) by book.ducksong.com (8.11.6/8.11.6) id g44HB4b01281 for dcp@ietf.org; Sat, 4 May 2002 13:11:04 -0400 Date: Sat, 4 May 2002 13:11:04 -0400 From: "Patrick R. McManus" To: dcp@ietf.org Message-ID: <20020504171104.GA1264@ducksong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [dcp] rcp-response packet reserved bits 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 4.6 defines the DCP-Response packet format. The diagram lists 8 reserved bits after the generic header, assumably for alignment purposes when combined with the 24 bit ack header. However, it doesn't list a required value for the reserved field. Is it really undefined or, like the 4 reserved bits in the generic header, are all 0's required at this stage? -P _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Sat May 4 13:17: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 NAA27097 for ; Sat, 4 May 2002 13:17:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28927 for dcp-archive@odin.ietf.org; Sat, 4 May 2002 13:17: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 NAA28908; Sat, 4 May 2002 13:17:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28877 for ; Sat, 4 May 2002 13:16:58 -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 NAA27092 for ; Sat, 4 May 2002 13:16:53 -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 g44HGY677806; Sat, 4 May 2002 10:16:45 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205041716.g44HGY677806@coyote.icir.org> To: "Asif Rahim" cc: dcp@ietf.org Reply-To: dcp@ietf.org Subject: Re: [dcp] dcp implementation.... In-Reply-To: Message from "Asif Rahim" of "Sat, 04 May 2002 17:57:37 +0600." <1A9272A914751640B9FA74C59F890A180150FA@galactica.firstbangla.com> Date: Sat, 04 May 2002 10:16:34 -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 Asif, There is no DCCP implementation as of yet, but several people who I think are on this list are working on it! Maybe they will send mail to the list when their implementations are ready for testing? Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Sat May 4 13:18:43 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 NAA27137 for ; Sat, 4 May 2002 13:18:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29005 for dcp-archive@odin.ietf.org; Sat, 4 May 2002 13:18:47 -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 NAA28991; Sat, 4 May 2002 13:18:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28960 for ; Sat, 4 May 2002 13:18:41 -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 NAA27119 for ; Sat, 4 May 2002 13:18: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 g44HIa677823; Sat, 4 May 2002 10:18:36 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205041718.g44HIa677823@coyote.icir.org> To: Ivan.Arias-Rodriguez@nokia.com cc: dcp@ietf.org Reply-To: dcp@ietf.org Subject: Re: [dcp] DCP comment: Support for IPv6 In-Reply-To: Message from Ivan.Arias-Rodriguez@nokia.com of "Sat, 04 May 2002 19:28:05 +0300." <58AEDE27D48F884285007ABF827FF26346A3E6@esebe017.NOE.Nokia.com> Date: Sat, 04 May 2002 10:18:36 -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 Ivan, > Obviously, there is no support for IPv6 addresses... You're right; that was an oversight. Derek Fawcus brought this up a couple weeks ago. Our current working draft changes the DCCP-Move packet format much like you suggest. Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Sat May 4 13:19: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 NAA27164 for ; Sat, 4 May 2002 13:19:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29076 for dcp-archive@odin.ietf.org; Sat, 4 May 2002 13:19:46 -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 NAA29062; Sat, 4 May 2002 13:19:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29032 for ; Sat, 4 May 2002 13:19:41 -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 NAA27159 for ; Sat, 4 May 2002 13:19:36 -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 g44HJc677841; Sat, 4 May 2002 10:19:38 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205041719.g44HJc677841@coyote.icir.org> To: "Patrick R. McManus" cc: dcp@ietf.org Subject: Re: [dcp] rcp-response packet reserved bits In-Reply-To: Message from "Patrick R. McManus" of "Sat, 04 May 2002 13:11:04 EDT." <20020504171104.GA1264@ducksong.com> Date: Sat, 04 May 2002 10:19:38 -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 for pointing this out. I think all 0's are required at this stage. Eddie > 4.6 defines the DCP-Response packet format. The diagram lists 8 > reserved bits after the generic header, assumably for alignment > purposes when combined with the 24 bit ack header. > > However, it doesn't list a required value for the reserved field. _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Sat May 4 15:14:46 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 PAA28231 for ; Sat, 4 May 2002 15:14:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03217 for dcp-archive@odin.ietf.org; Sat, 4 May 2002 15:14:50 -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 PAA03204; Sat, 4 May 2002 15:14:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03173 for ; Sat, 4 May 2002 15:14:45 -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 PAA28228 for ; Sat, 4 May 2002 15:14:39 -0400 (EDT) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id UAA21231 for dcp@ietf.org; Sat, 4 May 2002 20:14:13 +0100 (BST) Date: Sat, 4 May 2002 20:14:13 +0100 From: Derek Fawcus To: dcp@ietf.org Subject: Re: [dcp] DCP comment: Support for IPv6 Message-ID: <20020504201413.A21050@edinburgh.cisco.com> References: <58AEDE27D48F884285007ABF827FF26346A3E6@esebe017.NOE.Nokia.com> <200205041718.g44HIa677823@coyote.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200205041718.g44HIa677823@coyote.icir.org>; from kohler@icir.org on Sat, May 04, 2002 at 10:18:36AM -0700 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 Sat, May 04, 2002 at 10:18:36AM -0700, Eddie Kohler wrote: > Hi Ivan, > > > Obviously, there is no support for IPv6 addresses... > > You're right; that was an oversight. Derek Fawcus brought this up a couple > weeks ago. Our current working draft changes the DCCP-Move packet format > much like you suggest. Actually I don't like that whole approach (of embedding the address there). Mind I don't have a better suggestion at the moment, just a vague idea which I need to think about a bit more. I'd prefer some mechanism whereby a varient of the DCP-Request message could be used to add another address to an existing connection. This would then give both multihoming support and mobility support (by sending a DCP-Close once the new address has been added). This would obviously require some way to identify the connection without embedding the existing address pair. Possibly a varient on the mobility nonce that can encompass more info. DF _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Sat May 4 16:32:54 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 QAA28966 for ; Sat, 4 May 2002 16:32:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA05722 for dcp-archive@odin.ietf.org; Sat, 4 May 2002 16:32:59 -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 QAA05709; Sat, 4 May 2002 16:32:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05678 for ; Sat, 4 May 2002 16:32: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 QAA28961 for ; Sat, 4 May 2002 16:32:44 -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 g44KWl678689; Sat, 4 May 2002 13:32:47 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205042032.g44KWl678689@coyote.icir.org> To: Derek Fawcus cc: dcp@ietf.org Subject: Re: [dcp] DCP comment: Support for IPv6 In-Reply-To: Message from Derek Fawcus of "Sat, 04 May 2002 20:14:13 BST." <20020504201413.A21050@edinburgh.cisco.com> Date: Sat, 04 May 2002 13:32:47 -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 > I'd prefer some mechanism whereby a varient of the DCP-Request message > could be used to add another address to an existing connection. This > would then give both multihoming support and mobility support (by sending > a DCP-Close once the new address has been added). In some mobility scenarios, the mobile host couldn't send a DCCP-Close from its old address without spoofing. That aside, how different is this idea from DCCP-Move? I think of DCCP-Move like a simultaneous open and close. What does your plan buy us except for no embedded addresses? Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Tue May 7 11:34:23 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 LAA12761 for ; Tue, 7 May 2002 11:34:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05313 for dcp-archive@odin.ietf.org; Tue, 7 May 2002 11:34:29 -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 LAA05281; Tue, 7 May 2002 11:34:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05247 for ; Tue, 7 May 2002 11:34:13 -0400 (EDT) Received: from book.ducksong.com (pool-141-154-200-190.bos.east.verizon.net [141.154.200.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12744 for ; Tue, 7 May 2002 11:34:06 -0400 (EDT) Received: (from mcmanus@localhost) by book.ducksong.com (8.11.6/8.11.6) id g47FXe902489 for dcp@ietf.org; Tue, 7 May 2002 11:33:40 -0400 Date: Tue, 7 May 2002 11:33:40 -0400 From: "Patrick R. McManus" To: dcp@ietf.org Message-ID: <20020507153340.GA2453@ducksong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [dcp] sequence numbers on resend 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 quickie: 4.2 defines that a sequence number increases by one (modulo 2^24) for every packet sent. The spec isn't clear to me whether retransmissions (e.g. request and response) should follow this guideline. It seems to me they should not (and I'll work on that assumption) - I'm just noting a way that the spec could be clearer. -Pat _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Tue May 7 13:05: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 NAA15959 for ; Tue, 7 May 2002 13:05:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12193 for dcp-archive@odin.ietf.org; Tue, 7 May 2002 13:05: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 NAA12184; Tue, 7 May 2002 13:05:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12149 for ; Tue, 7 May 2002 13:05:04 -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 NAA15954 for ; Tue, 7 May 2002 13:04:56 -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 g47H4x610034; Tue, 7 May 2002 10:04:59 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205071704.g47H4x610034@coyote.icir.org> To: "Patrick R. McManus" cc: dcp@ietf.org Reply-To: dcp@ietf.org Subject: Re: [dcp] sequence numbers on resend In-Reply-To: Message from "Patrick R. McManus" of "Tue, 07 May 2002 11:33:40 EDT." <20020507153340.GA2453@ducksong.com> Date: Tue, 07 May 2002 10:04:59 -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 > 4.2 defines that a sequence number increases by one (modulo 2^24) for > every packet sent. > > The spec isn't clear to me whether retransmissions (e.g. request and > response) should follow this guideline. You're right. We need to be clearer about retransmissions at the start of a connection. My first instincts are: (1) DCCP-Responses are never retransmitted. If a Response is lost, the side that initiated the connection will retransmit the Request eventually. (2) I'm not sure it matters, in practice, whether retransmitted Requests have new sequence numbers. Therefore, for consistency, I would choose that they would. Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Tue May 7 13:13:40 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 NAA16536 for ; Tue, 7 May 2002 13:13:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12916 for dcp-archive@odin.ietf.org; Tue, 7 May 2002 13:13:47 -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 NAA12861; Tue, 7 May 2002 13:13:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12832 for ; Tue, 7 May 2002 13:13:28 -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 NAA16509 for ; Tue, 7 May 2002 13:13:20 -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 g47HDQk92944; Tue, 7 May 2002 10:13:26 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: dcp@ietf.org cc: "Patrick R. McManus" Subject: Re: [dcp] sequence numbers on resend In-reply-to: Your message of "Tue, 07 May 2002 10:04:59 PDT." <200205071704.g47H4x610034@coyote.icir.org> Date: Tue, 07 May 2002 10:13:26 -0700 Message-ID: <92942.1020791606@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 >(2) I'm not sure it matters, in practice, whether retransmitted Requests >have new sequence numbers. Therefore, for consistency, I would choose that >they would. The advantage of this is that it's easy to tell which Request packet got through, so you can initialize RTT measurements correctly. The disadvantage would be that you have to be prepared to accept a Response acking any of the Request sequence numbers you've sent for this connection. So using new sequence numbers seems to be a win on balance, but it is slightly more complex. - Mark _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Tue May 7 13:22:01 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 NAA16883 for ; Tue, 7 May 2002 13:22:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13378 for dcp-archive@odin.ietf.org; Tue, 7 May 2002 13:22:08 -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 NAA13369; Tue, 7 May 2002 13:21:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13334 for ; Tue, 7 May 2002 13:21:56 -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 NAA16878 for ; Tue, 7 May 2002 13:21:48 -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 g47HLp610132; Tue, 7 May 2002 10:21:51 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205071721.g47HLp610132@coyote.icir.org> To: Mark Handley cc: dcp@ietf.org, "Patrick R. McManus" Subject: Re: [dcp] sequence numbers on resend In-Reply-To: Message from Mark Handley of "Tue, 07 May 2002 10:13:26 PDT." <92942.1020791606@aardvark.icir.org> Date: Tue, 07 May 2002 10:21:51 -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 > The advantage of this is that it's easy to tell which Request packet > got through, so you can initialize RTT measurements correctly. The > disadvantage would be that you have to be prepared to accept a > Response acking any of the Request sequence numbers you've sent for > this connection. This isn't so hard if you just increase the Request sequence number by one for each retransmission, like you'd do for any other packet on the connection. Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Tue May 7 13:50:59 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 NAA18203 for ; Tue, 7 May 2002 13:50:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15144 for dcp-archive@odin.ietf.org; Tue, 7 May 2002 13:51:06 -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 NAA14923; Tue, 7 May 2002 13:49:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14885 for ; Tue, 7 May 2002 13:49:16 -0400 (EDT) Received: from book.ducksong.com (pool-141-154-200-190.bos.east.verizon.net [141.154.200.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18078 for ; Tue, 7 May 2002 13:49:08 -0400 (EDT) Received: (from mcmanus@localhost) by book.ducksong.com (8.11.6/8.11.6) id g47Hme701210 for dcp@ietf.org; Tue, 7 May 2002 13:48:40 -0400 Date: Tue, 7 May 2002 13:48:40 -0400 From: "Patrick R. McManus" To: dcp@ietf.org Subject: Re: [dcp] sequence numbers on resend Message-ID: <20020507174840.GA1191@ducksong.com> References: <20020507153340.GA2453@ducksong.com> <200205071704.g47H4x610034@coyote.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205071704.g47H4x610034@coyote.icir.org> User-Agent: Mutt/1.3.28i 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 first instincts are: > > (1) DCCP-Responses are never retransmitted. If a Response is lost, the side > that initiated the connection will retransmit the Request eventually. correlary: t3 needs to be very large. This could lead to some pretty big tables of timers not associated with real sessions. > > (2) I'm not sure it matters, in practice, whether retransmitted Requests > have new sequence numbers. Therefore, for consistency, I would choose that > they would. I'd argue against it for a few reasons: 1] the above - using the same ISN would let you use the same connection and not have orphaned timers. 2] (rvcd_ackn == local_isn) has to match on each side to complete the handshake.. extending that to (rcvd_ackn is_in list_of_local_isns) is an implementation hassle - requiring state maintenance for each resend. 3] least surprise - in TCP a retransmit is a RE-transmit, the same TCP level data is simply sent again. this way you only have to worry about dups not which one is "right". _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Tue May 7 15:41:52 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 PAA21925 for ; Tue, 7 May 2002 15:41:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14809 for dcp-archive@odin.ietf.org; Tue, 7 May 2002 15:41:59 -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 PAA14643; Tue, 7 May 2002 15:41:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14459 for ; Tue, 7 May 2002 15:41:35 -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 OAA18655 for ; Tue, 7 May 2002 14:01:47 -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 g47I1o610384; Tue, 7 May 2002 11:01:50 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205071801.g47I1o610384@coyote.icir.org> To: "Patrick R. McManus" cc: dcp@ietf.org Subject: Re: [dcp] sequence numbers on resend In-Reply-To: Message from "Patrick R. McManus" of "Tue, 07 May 2002 13:48:40 EDT." <20020507174840.GA1191@ducksong.com> Date: Tue, 07 May 2002 11:01:50 -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 > 1] the above - using the same ISN would let you use the same > connection and not have orphaned timers. The connection is uniquely identified by the port numbers [and Service Name]. A retransmitted Request will have the same port numbers, so there's only one connection, and no orphaned timers. > 3] least surprise - in TCP a retransmit is a RE-transmit, the same > TCP level data is simply sent again. this way you only have to worry > about dups not which one is "right". Well, in DCCP, every packet increments the sequence number, including pure acks (and retransmitted pure acks). Therefore I think incrementing the Request sequence number would surprise the least. > 2] (rvcd_ackn == local_isn) has to match on each side to complete > the handshake.. extending that to (rcvd_ackn is_in > list_of_local_isns) is an implementation hassle - requiring state > maintenance for each resend. I agree with this concern, although I don't think the hassle would be that serious. It's not a new kind of state, after all; it's just like the state DCCP endpoints maintain for established connections. Again, it doesn't seem like a big deal either way. I prefer incrementing the sequence number for internal consistency, and because it provides more information to the endpoints. With incremented sequence numbers, the endpoints need to handle old (= delayed) and duplicated Requests and Responses. With identical sequence numbers, the endpoints need to handle duplicated Requests and Responses. The logic will be basically the same. Doesn't seem that much easier. Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Tue May 7 17:17:33 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 RAA24431 for ; Tue, 7 May 2002 17:17:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21237 for dcp-archive@odin.ietf.org; Tue, 7 May 2002 17:17:39 -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 RAA21224; Tue, 7 May 2002 17:17:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21193 for ; Tue, 7 May 2002 17:17:27 -0400 (EDT) Received: from pig.ftannei.com (pig.ftannei.com [64.81.246.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24425 for ; Tue, 7 May 2002 17:17:20 -0400 (EDT) Received: from pig.ftannei.com (localhost [127.0.0.1]) by pig.ftannei.com (8.12.3/8.11.6) with ESMTP id g47LGOfo056743; Tue, 7 May 2002 14:16:24 -0700 (PDT) (envelope-from alkis@ftannei.com) Content-Type: text/plain; charset="us-ascii" From: Alkis Evlogimenos To: dcp@ietf.org Date: Tue, 7 May 2002 14:16:23 -0700 X-Mailer: KMail [version 1.4] Cc: dcp@daedalus.cs.berkeley.edu MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200205071416.23908.alkis@ftannei.com> Content-Transfer-Encoding: 8bit Subject: [dcp] flow window 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: 8bit Hi all, I am an undergraduate student in UC Berkeley and currently working (along with 3 other students) on a user space implementation of the DCCP protocol. We believe that adding a flow window option to the DCCP protocol will be very beneficial in at least 3 areas: case of slow receiver, detection of valid sequence numbers and the requirement for acknowledgements of acknowledgemens and ack vector implementation. More specifically: a) The case of slow receiver: since the sender will know the available window on the receiving side it will never overload the receiver with excess traffic. Without a flow window the protocol will simply send packets until the receiver drops one. At that point the congestion mechanism will kick in and slow down the sender, but at that point the receiver is already overloaded. It is also worth noting that a change in the rate of the sender must take at least one RTT from the time of the drop and this latency may be unacceptable in some situations. b) valid sequence number: with a flow window it is easy to choose between valid and invalid sequence numbers. Everything inside is valid, otherwise invalid. This is currently an unsolved issue with the current specification. c) acks of acks: With a flow window there is no need for acks of acks. Here are possible two issues with acks of acks: i) Hard to keep track of what to send back in the ack vector. The receiver must keep state of what sender sequence number it acked with which packet, in order to be able to clear the state correctly. Even with that information at hand there are still some corner cases to take care of (section 7.8.3 in the draft). ii) If the link is severely asymmetricm the ack of acks requirement may cause throughput problems (with asymmetric I mean every asymmetry possible - asymmetry in bandwidth, rtt, loss percentage). The proposal here is to require that ack vector is acknowledging a flow window worth of packets each time. This will guarantee a reliable transmition of all acks and also alleviate the need for acks of acks. It will also make the ack vector implementation much simpler. Comments/ideas? Thanks, Alkis Evlogimenos UC Berkeley _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Tue May 7 21:38: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 VAA29695 for ; Tue, 7 May 2002 21:38:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04613 for dcp-archive@odin.ietf.org; Tue, 7 May 2002 21:38:59 -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 VAA04603; Tue, 7 May 2002 21:38:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04568 for ; Tue, 7 May 2002 21:38:47 -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 VAA29690 for ; Tue, 7 May 2002 21:38:39 -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 g481cg613065; Tue, 7 May 2002 18:38:42 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205080138.g481cg613065@coyote.icir.org> To: Alkis Evlogimenos cc: dcp@ietf.org, dcp@daedalus.cs.berkeley.edu Subject: Re: [dcp] flow window In-Reply-To: Message from Alkis Evlogimenos of "Tue, 07 May 2002 14:16:23 PDT." <200205071416.23908.alkis@ftannei.com> Date: Tue, 07 May 2002 18:38:42 -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 Alkis, thanks for your message, which brought up a bunch of issues we need to deal with! We don't believe that a flow window makes sense for DCCP. Take the two existing CCIDs, TFRC and TCP-like. * For TFRC, any kind of flow window doesn't make sense. A window doesn't really match up with a rate-based protocol, there is no Ack Vector to carry flow window information, and TFRC's slow increase strategy would make recovery from transient receiver congestion a painful process. The 'slow receiver' and 'sequence number validity' problems are generic DCCP problems, whose solutions should work for all CCIDs. Since flow windows don't work for TFRC, let's agree that the solutions for 'slow receiver' and 'sequence number validity' will not involve a flow window. This leaves the 'ack of acks' problem, which is relevant only for TCP-like CC. * For TCP-like congestion control, a flow window seems more sensible; after all, TCP has one. However, in DCCP, a flow window might actually complicate the 'ack of acks' problem, since acks are not cumulative, and DCCP's ack clocking can be much slower than TCP's. How should the flow window move when an Ack Vector indicates loss or congestion in the middle of a 'window'? Or at the beginning of a 'window'? What if a whole 'window' of packets is lost? The sender would go quiescent, unable to send anything until the 'window' reopened, so there would have to be a timeout, after which the receiver would send an ack to restart the sender. What about reverse-path congestion, where Ack Ratio gets high? Then the receiver cannot send very many acks, so the flow window would get updated only sporadically, causing bursty sending. There may be other issues too. Overall it doesn't seem any less complicated than the current ack-of-acks logic. The three problems you mention are real, though. We decided on solutions that we preferred, as follows: > a) The case of slow receiver: since the sender will know the available window > on the receiving side it will never overload the receiver with excess > traffic. Without a flow window the protocol will simply send packets until > the receiver drops one. We propose a one-byte option, meaning, roughly, "Receiver Reaching Capacity, Please Don't Send Faster". The receiver will put this option on Ack packets to indicate that this DCP connection is reaching the limit of the receiver's CPU, buffer space, or what-have-you. (We believe CPU is the most likely limiting factor for today's machines.) Upon receiving this option, the sender will refrain from increasing its send rate for one RTT (send rate interpreted according to the sender's CCID). Thus, the receiver should keep sending the option until it gets some spare CPU, buffer space, or what-have-you. The sending application can use some API to find out whether its rate is limited by network congestion or receiver congestion (= "Reaching Capacity" and "Receive Buffer Drops"). It may respond differently to the two kinds of congestion. For example, if the network is congested, the sender might switch to a more compressed format; whereas if the receiver is congested, the sender might switch to a _less_ compressed format, to reduce CPU pressure. DCCP doesn't require any particular application behavior, of course, but it's nice to provide the hooks. Note that "Receiver Reaching Capacity" is inherently less precise about the receiver's limitations than TCP's receive window. This can be seen as an advantage. > b) valid sequence number: with a flow window it is easy to choose between > valid and invalid sequence numbers. Everything inside is valid, otherwise > invalid. This is currently an unsolved issue with the current specification. We propose a non-negotiable feature, "Valid Sequence Space", which the sender uses to inform the receiver of how big the valid sequence space should be. The sender should control this number, not the receiver, since only the sender can estimate how many packets it might send. (A flow window would confuse two concepts here: how much the sender might send, and how much the receiver wants to receive.) A reasonable guideline: the sender will set "Valid Sequence Space" to the maximum number of packets it expects to send in any RTT, times 4 or 8. "Valid Sequence Space" will default to, say, 512. > c) acks of acks: With a flow window there is no need for acks of acks. Here > are possible two issues with acks of acks: > i) Hard to keep track of what to send back in the ack vector. The receiver > must keep state of what sender sequence number it acked with which packet, in > order to be able to clear the state correctly. Even with that information at > hand there are still some corner cases to take care of (section 7.8.3 in the > draft). You are right. Acks of acks are hard. There's no way around it. But they are necessary. Hopefully we've explained why flow windows don't necessarily make it any easier. We didn't quite understand your point about asymmetric links, but maybe this is enough for now. Thanks for bringing up these good points! Eddie, with Mark and Sally _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Wed May 8 12:39:52 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 MAA15982 for ; Wed, 8 May 2002 12:39:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13220 for dcp-archive@odin.ietf.org; Wed, 8 May 2002 12:39:59 -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 MAA13205; Wed, 8 May 2002 12:39:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13174 for ; Wed, 8 May 2002 12:39:47 -0400 (EDT) Received: from book.ducksong.com (pool-141-154-200-190.bos.east.verizon.net [141.154.200.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15975 for ; Wed, 8 May 2002 12:39:39 -0400 (EDT) Received: (from mcmanus@localhost) by book.ducksong.com (8.11.6/8.11.6) id g48GdGn02019; Wed, 8 May 2002 12:39:16 -0400 Date: Wed, 8 May 2002 12:39:16 -0400 From: "Patrick R. McManus" To: Eddie Kohler Cc: dcp@ietf.org Subject: Re: [dcp] sequence numbers on resend Message-ID: <20020508163916.GA1532@ducksong.com> References: <20020507174840.GA1191@ducksong.com> <200205071801.g47I1o610384@coyote.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205071801.g47I1o610384@coyote.icir.org> User-Agent: Mutt/1.3.28i 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 more thoughts on resending requests - what about requests with data? Warning, this scenario may not be fully baked - I've just started toying with it. the state diagram says you only count that data once (requests outside of LISTENING are ignored).. t0: xmit A->B Req SN=0 with data t3: xmit A->B Req SN=1 with data t5: rcv A->B Req SN=1 with data t5: xmit B->A Resp SN=0 ack=1 vector=0,192 t6: rcv A->B Req SN=0 with data (dropped as we're in APP-ACCEPT) t7: rcv B->A Resp SN=0 ack=1 vector=0,192 .. so the client (A) now has only 1 of 2 xmitted packets ack'd.. this is fine, as it was true when B generated the ack vector.. however new ack vectors at times > 6 will still represent sn=0 as unreceived (which is untrue) and will impinge on A's cwnd for a while. if A retransmits with the same isn (because it's the same data he is only expecting one ack bit for) this problem goes away. -Patrick _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Wed May 8 12:58:54 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 MAA16419 for ; Wed, 8 May 2002 12:58:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14401 for dcp-archive@odin.ietf.org; Wed, 8 May 2002 12:59: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 MAA14388; Wed, 8 May 2002 12:58:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14357 for ; Wed, 8 May 2002 12:58:48 -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 MAA16392 for ; Wed, 8 May 2002 12:58:40 -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 g48Gwjk11343; Wed, 8 May 2002 09:58:45 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: "Patrick R. McManus" cc: Eddie Kohler , dcp@ietf.org Subject: Re: [dcp] sequence numbers on resend In-reply-to: Your message of "Wed, 08 May 2002 12:39:16 EDT." <20020508163916.GA1532@ducksong.com> Date: Wed, 08 May 2002 09:58:45 -0700 Message-ID: <11341.1020877125@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 >t0: xmit A->B Req SN=0 with data >t3: xmit A->B Req SN=1 with data > >t5: rcv A->B Req SN=1 with data >t5: xmit B->A Resp SN=0 ack=1 vector=0,192 >t6: rcv A->B Req SN=0 with data (dropped as we're in APP-ACCEPT) > >t7: rcv B->A Resp SN=0 ack=1 vector=0,192 >however new ack vectors at times > 6 will still represent >sn=0 as unreceived (which is untrue) and will impinge on A's cwnd for >a while. How does the receiver even know that sn=0 was sent? The ack vector it sends at t5 wouldn't cover 0 because the request ISN was 1. However the sender knows it was sent, and should act accordingly. >if A retransmits with the same isn (because it's the same data he is >only expecting one ack bit for) this problem goes away. The flipside is that if you send with the same ISN, in the same scenario, you also can't tell if the first packet was lost or not. The sender MUST assume it was lost (it sent two SYNs, got one ACK). So the problem is very similar, but there's less information if you don't increment ISN for the sender to go on. If you want to solve this corner-case problem correctly, I think you need to increment the ISN, and in this case back off the start of the ack-vector to 0 when you get the delayed request at t6 (you don't completely ignore it - it just doesn't cause a state-machine transition). Cheers, Mark _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Sat May 18 23:00:48 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 XAA11519 for ; Sat, 18 May 2002 23:00:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08130 for dcp-archive@odin.ietf.org; Sat, 18 May 2002 23:01:04 -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 XAA08055; Sat, 18 May 2002 23:00:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08021 for ; Sat, 18 May 2002 23:00:53 -0400 (EDT) Received: from ducksong.com (pool-141-154-203-61.bos.east.verizon.net [141.154.203.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11509 for ; Sat, 18 May 2002 23:00:33 -0400 (EDT) Received: (from mcmanus@localhost) by ducksong.com (8.11.6/8.11.6) id g4J2xGn01639 for dcp@ietf.org; Sat, 18 May 2002 22:59:16 -0400 Date: Sat, 18 May 2002 22:59:16 -0400 From: "Patrick R. McManus" To: dcp@ietf.org Message-ID: <20020519025916.GA1629@ducksong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [dcp] A new DCP Implementation 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 Folks, I've been working on a DCCP implementation for research purposes. Judging by the "release early and often" standard it is time to share what I've got. (Judging by any other sane standard of quality control it's far too early ;). The implementation is for Linux - it runs at the kernel level directly on top of IP. My patches are against version 2.4.18 - the patches are licensed as GPL code. http://www.ducksong.com:81/dccp/ There is a whole litany of things known to be done still - as well as I'm sure many problems with the existing code. That notwithstanding, what is there is pretty functional - socket(), bind(), accept(), connect(), send(), recv(), and close() work and push data around the network. Certainly there is enough for people to play with a little, and maybe even (hopefully?) post patches against. The code definitely takes a correctness before optimization approach - and there is no doubt work to be done on the correctness front before even pondering optimization. Be forewarned. A partial list of things I have no support for (consider this a partial TODO list) ECN, Move Types, Poll(), buffered sends (send will block if congestion control dictates), variable recv buffer sizes, ccid 3, service names other than 0, sending/recving data on handshake, using timestamps for rtt samples. There's also a security problem or two (I let you grow the ackvector infinitely for example - bad idea in kernel space.) but still, its a good start. Feedback is welcome. -Patrick _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Tue May 21 17:30:59 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 RAA01572 for ; Tue, 21 May 2002 17:30:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16666 for dcp-archive@odin.ietf.org; Tue, 21 May 2002 17:31:18 -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 RAA16655; Tue, 21 May 2002 17:31:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16622 for ; Tue, 21 May 2002 17:31:04 -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 RAA01555 for ; Tue, 21 May 2002 17:30: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 g4LLUl637020 for ; Tue, 21 May 2002 14:30:47 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205212130.g4LLUl637020@coyote.icir.org> To: dcp@ietf.org Subject: [dcp] spec updates, terminology Date: Tue, 21 May 2002 14:30:47 -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 all, Thought we'd keep you all up to date on some recent changes to DCCP. Many of these changes were brought up on the mailing list; thanks! * We've added a pseudoheader to the DCCP checksum calculation. * We're ironing out the "sequence number validity" issue (Section 4.3). A new Loss Window feature defines a loss window width; a new Connection Nonce feature, and associated options, facilitate getting back into sync after long bursts of loss. * The DCCP-Move packet format has changed. The Old Address can take other forms than an IPv4 address, and the Mobility Nonce was removed, in favor of a connection-nonce option. * A new Slow Receiver option lets a receiver tell a sender that it is having trouble keeping up. * We've fleshed out the section on acks-of-acks, hopefully reducing confusion. And now, a question. We're starting to dislike the names of the feature negotiation options (Ask, Choose, and Answer). Any suggestions? Our current top choice is Change (for Ask), Prefer (for Choose), and Done (for Answer). We will probably release a new draft within a week or so. Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Wed May 22 11:32: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 LAA11298 for ; Wed, 22 May 2002 11:32:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02858 for dcp-archive@odin.ietf.org; Wed, 22 May 2002 11:32:29 -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 LAA02840; Wed, 22 May 2002 11:32: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 LAA02809 for ; Wed, 22 May 2002 11:32:10 -0400 (EDT) Received: from book.ducksong.com (pool-141-154-203-61.bos.east.verizon.net [141.154.203.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11229 for ; Wed, 22 May 2002 11:31:49 -0400 (EDT) Received: (from mcmanus@localhost) by book.ducksong.com (8.11.6/8.11.6) id g4MFWAX03519; Wed, 22 May 2002 11:32:10 -0400 Date: Wed, 22 May 2002 11:32:10 -0400 From: "Patrick R. McManus" To: Eddie Kohler Cc: dcp@ietf.org Subject: Re: [dcp] spec updates, terminology Message-ID: <20020522153210.GB2813@ducksong.com> References: <200205212130.g4LLUl637020@coyote.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205212130.g4LLUl637020@coyote.icir.org> User-Agent: Mutt/1.3.28i 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 [Eddie Kohler: Tue, May 21, 2002 at 02:30:47PM -0700] > > * We're ironing out the "sequence number validity" issue (Section 4.3). A > new Loss Window feature defines a loss window width; a new Connection > Nonce feature, and associated options, facilitate getting back into sync > after long bursts of loss. this is good news, my implementation more or less punts on this one (it uses a fixed window which it just drops packets that are outside of) on the assumption that a better definition would come along ;) > > And now, a question. We're starting to dislike the names of the feature > negotiation options (Ask, Choose, and Answer). Any suggestions? Our current > top choice is Change (for Ask), Prefer (for Choose), and Done (for Answer). My notes have referred to them as: assign/set, menu, confirmed. _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Fri May 24 15:46:20 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 PAA12125 for ; Fri, 24 May 2002 15:46:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17074 for dcp-archive@odin.ietf.org; Fri, 24 May 2002 15:46:42 -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 PAA17049; Fri, 24 May 2002 15:46:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17018 for ; Fri, 24 May 2002 15:46:31 -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 PAA12098 for ; Fri, 24 May 2002 15:46:07 -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 g4OJkS681208 for ; Fri, 24 May 2002 12:46:28 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200205241946.g4OJkS681208@coyote.icir.org> To: dcp@ietf.org Subject: [dcp] new Internet-Drafts Date: Fri, 24 May 2002 12:46:28 -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 all, We've released new Internet-Drafts for DCCP and DCCP CCIDs 2 and 3. The DCCP draft has substantial new stuff; changes in the CCID drafts are mostly cosmetic. Downloadable from http://www.icir.org/kohler/dccp/ Changes in DCCP since -02: Changed name of protocol; renamed options; new state diagram; new Loss Window and Connection Nonce options/features address sequence number validity; Slow Receiver option; DCCP checksum includes a pseudoheader; Move packet format changed; added explanation of acks-of-acks. Thanks! Eddie _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@optimus.ietf.org Wed May 29 06:28:52 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 GAA09871 for ; Wed, 29 May 2002 06:28:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29167 for dcp-archive@odin.ietf.org; Wed, 29 May 2002 06:29: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 GAA29158; Wed, 29 May 2002 06:29:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29122 for ; Wed, 29 May 2002 06:29:03 -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 GAA09866 for ; Wed, 29 May 2002 06:28:38 -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 g4TAT1mG027349 for ; Wed, 29 May 2002 12:29:01 +0200 (MEST) Received: by lms001.lu.erisoft.se id MAA03232; Wed, 29 May 2002 12:29:01 +0200 (MET DST) Message-ID: <3CF4AD6C.90A9F226@epl.ericsson.se> Date: Wed, 29 May 2002 12:29:00 +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] Window counter 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! As I understand it the purpose of the window counter option (CCID 3) is to replace the RTT estimate. Basically the receiver needs to know the RTT in order to report the current receive rate and to know when to send feedback among other things. My question is how the window counter option is to be used for this. By the way, is it still recommended that the sender increases the window counter by 4 once it receives a report of a congestion event? /Sara _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp From daemon@ns.ietf.org Thu May 30 21:08:12 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 VAA23363 for ; Thu, 30 May 2002 21:08:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA15915 for dcp-archive@odin.ietf.org; Thu, 30 May 2002 21:08:38 -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 VAA15885; Thu, 30 May 2002 21:08:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15852 for ; Thu, 30 May 2002 21:08:20 -0400 (EDT) Received: from book.ducksong.com (pool-141-154-203-61.bos.east.verizon.net [141.154.203.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23356 for ; Thu, 30 May 2002 21:07:53 -0400 (EDT) Received: (from mcmanus@localhost) by book.ducksong.com (8.11.6/8.11.6) id g4V18SO02613 for dcp@ietf.org; Thu, 30 May 2002 21:08:28 -0400 Date: Thu, 30 May 2002 21:08:27 -0400 From: "Patrick R. McManus" To: dcp@ietf.org Subject: Re: [dcp] A new DCP Implementation Message-ID: <20020531010827.GA2579@ducksong.com> References: <20020519025916.GA1629@ducksong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020519025916.GA1629@ducksong.com> User-Agent: Mutt/1.3.28i 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 [pat atducksong: Sat, May 18, 2002 at 10:59:16PM -0400] > I've been working on a DCCP implementation for research > purposes. Judging by the "release early and often" standard it is time > to share what I've got. (Judging by any other sane standard of quality > control it's far too early ;). It has been a little while since I sent an update, so I thought I'd do that. I haven't been able to invest a whole lot of time in DCCP, but there has been some significant progress over the last 10 days or so: * listen() * poll() [and there was much rejoicing..] * service names [1] * payload allowed on both request and response [2] * lookaside buffer cache allocations * numerous crashing bugs * a memory leak or two * hashes on the lookup lists The patches are still against linux's 2.4.18 vanilla kernel and are always linked off of: http://www.ducksong.com:81/dccp/ I want to mention the API I used for a couple of features, as it does impact user space. Probably not the kind of thing apropos for the specification, but it would be nice if different implementations had complimentary apis - these aren't set in stone (heck the whole thing is just a research implementation) so please comment. [1] service names - I introduced a new structure struct sockaddr_dcp { struct sockaddr_in in; unsigned int service; }; which may be passed to bind() or connect() in lieu of the more traditional sockaddr_in. Its completely compatible with a ported UDP ap that uses sockaddr_in though, the stack just assumes service name of 0 in that case. [2] handshake payloads. Initially, the server needs a way to identify whether or not it should accept data attached to a request or if it should answer with option=discard (option 1).. if a client gets the discard option on the response packet it will resend the data on with its ack. The server's socket can be told to allow/disallow request data via a setsockopt setsockopt (s, SOL_DCCP, SO_ALLOW_HANDSHAKE_DATA, (void *) &y, sizeof (int))); similarly, setsockopt is used to "preload" data before calling connect() or accept().. setsockopt (s, SOL_DCCP, SO_HANDSHAKE_DATA, (void *) buf, 225); the data on a bound socket will apply to every accept() done off of it.. though that data can be modified/canceled by subsequent setsockopt() calls. no actual data is returned by the accept() or connect() calls even if the other side has sent some on the handshake - its just put into the buffers for the next recv(). -P _______________________________________________ dcp mailing list dcp@ietf.org https://www1.ietf.org/mailman/listinfo/dcp