headers
Joel M. Halpern | 3 Aug 2005 16:25

Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard

For peoples information, DCCP is now approved for publication as a PS.

Yours,
Joel

>From: The IESG <iesg-secretary <at> ietf.org>
>To: IETF-Announce <ietf-announce <at> ietf.org>
>Date: Wed, 03 Aug 2005 10:13:54 -0400
>Subject: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to 
>Proposed Standard
>
>The IESG has approved the following document:
>
>- 'Datagram Congestion Control Protocol (DCCP) '
>    <draft-ietf-dccp-spec-11.txt> as a Proposed Standard
>
>This document is the product of the Datagram Congestion Control Protocol
>Working Group.
>
>The IESG contact persons are Allison Mankin and Jon Peterson.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-dccp-spec-11.txt
>
>*Â  Â  Technical Summary
>
>The Datagram Congestion Control Protocol (DCCP) is a transport
>protocol that provides bidirectional unicast connections of
>congestion-controlled unreliable datagrams.  DCCP is suitable for
>applications that transfer fairly large amounts of data, but can
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dong Ligang | 4 Aug 2005 01:48
Picon

Re: Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard

Yes, it is probably time to replace TCP-TCP using TCP-DCCP . 
The performance evaulation is required to use it in TML.
Permalink | Reply | 0 comments |
headers
Khosravi, Hormuzd M | 4 Aug 2005 02:09
Picon
Favicon

Re: Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard

Yes indeed. And in order to do a performance evaluation we need a stable
implementation of this protocol (preferably on Linux) that can be tested
against TCP. I have been looking for one for more than a year now and
haven't had any luck. I know that Jamal was guiding someone in the Linux
community to work on this but not sure if that resulted in a stable DCCP
implementation.

If anyone has more info on this pls do let us know.

Thanks
Hormuzd 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Dong Ligang
Sent: Wednesday, August 03, 2005 4:48 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] Fwd: Protocol Action: 'Datagram Congestion Control
Protocol (DCCP)' to Proposed Standard

Yes, it is probably time to replace TCP-TCP using TCP-DCCP . 
The performance evaulation is required to use it in TML.
Permalink | Reply | 1 comment |
headers
Dong Ligang | 4 Aug 2005 06:38
Picon

Re: Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard

Yes, if anyone get a copy of DCCP implemenation, please share with us.
I would like to spend time on this experiment. 
Besides, I think TCP-UDP+schedule can have similar effect.
Permalink | Reply | 0 comments |
headers
Wang,Weiming | 5 Aug 2005 06:31
Picon

IPTML draft

Hi,

Seems I forgot to make a note to the list.
 
http://www.ietf.org/internet-drafts/draft-wang-forces-iptml-00.txt is a draft on IPTML that we
submitted before the deadline.  The transmission scheme is based on TCP+UDP, called TCP-UDP pair
connections.  More experiments are being carried on, and we are going to present more experiment results
on this scheme soon. 

Hope to get comments from you.

Thanks,

Weiming
Permalink | Reply | 0 comments |
headers
Dong Ligang | 5 Aug 2005 14:39
Picon

A old suggestion. Welcome your comments.

1) [Page 14] Remove the definition of ACID, as ACID is a well known
concept. In this ForCES Specification, we do not provide new information
about the definition of ACID.
Permalink | Reply | 1 comment |
headers
Dong Ligang | 5 Aug 2005 15:13
Picon

about transaction

Transaction's discuss in the ForCES Protocol has lasted for a long time. 
Till now there exist "TBD" and "not sure"in the protocol. Why not we 
temporarily impose some limitations to reduce the complexity. For examples, 
we let transaction exist only in the situation of one CE vs. one FE. In 
other words, we will not consider the transaction in multicast/broadcast.
Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 6 Aug 2005 01:23

Re: A old suggestion: ACID text removal

Actually, I like having the definition in the document.  It does not take 
up much space, and is very helpful to the reader.  Remember that the 
average reader probably will not be a database or transaction processing 
oriented person.
Heck, until we started this discussion I could not have reconstructed what 
ACID properties of transactions were, and I have seen them before.

Yours,
Joel

At 08:39 AM 8/5/2005, Dong Ligang wrote:
>1) [Page 14] Remove the definition of ACID, as ACID is a well known
>concept. In this ForCES Specification, we do not provide new information
>about the definition of ACID.
Permalink | Reply | 0 comments |
headers
Dong Ligang | 9 Aug 2005 03:32
Picon

Re: A old suggestion: ACID text removal

Joel, thank you for your reply.

The draft has already provided the reference of ACID. Even you do not konw 
the meaning of ACID, you can still understand the draft. 
I think simpler is better.
Permalink | Reply | 0 comments |
headers
Robert Haas | 9 Aug 2005 13:54
Picon
Favicon

ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005.

Hi All,
Below are the minutes of the Aug 1st 2005 ForCES WG meeting in Paris.
Presentations are available at:
http://www.zurich.ibm.com/~rha/forces-ietf63-presentations.zip

Regards,
-Robert

IETF ForCES wg meeting, ietf63, Paris, Aug 1, 2005, 10h30-12h30.

Robert Haas and Alex Zinin chairing the meeting.

1) administratrivia (Robert Haas, 4 min)

Presentation: forces-ietf63-chairing-haas.ppt

Consider last call for protocol and model drafts before ietf-64.
Attendance/list is asked to participate in preparing the MIB draft(s)
and LFB library draft(s). Also, existing or in-progress implementations
should be reported to the list.

2) Flexinet presentation (Robert Haas, 6 min)

Presentation: forces-ietf63-flexinet-haas.ppt

Description of the basic and extendable function blocks in the Hitachi
modular router. Packets received by the NE are directed to one or more
other FEs for packet treatment, which requires metadata exchange among
FEs (future scope). Description of the ForCEG (ForCES CE Gateway) used
to gateway between services such as AAA Proxy and QoS and the FEs,
(Continue reading)

Permalink | Reply | 81 comments |

Gmane