From mailman-bounces@ietf.org Tue Jun 1 07:27:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18288 for ; Tue, 1 Jun 2004 07:27:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV7Qw-0002ng-8j for tsvwg-archive@ietf.org; Tue, 01 Jun 2004 07:27:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV7Q1-0002Np-00 for tsvwg-archive@ietf.org; Tue, 01 Jun 2004 07:26:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BV7PP-0001vX-00 for tsvwg-archive@ietf.org; Tue, 01 Jun 2004 07:26:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5V6-0002VB-9z for tsvwg-archive@ietf.org; Tue, 01 Jun 2004 05:24:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tsvwg-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Jun 2004 05:04:10 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for tsvwg-archive@ietf.org: List Password // URL ---- -------- tsvwg@ietf.org xeowbe https://www1.ietf.org/mailman/options/tsvwg/tsvwg-archive%40ietf.org From mailman-admin@ietf.org Tue Jun 1 11:20:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13999 for ; Tue, 1 Jun 2004 11:20:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVB4J-0005GB-Ms for tsvwg-archive@ietf.org; Tue, 01 Jun 2004 11:20:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVB2g-0004gP-00 for tsvwg-archive@ietf.org; Tue, 01 Jun 2004 11:19:07 -0400 Received: from jupiter.cnri.reston.va.us ([132.151.1.18] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BVB1f-0004Bj-00 for tsvwg-archive@ietf.org; Tue, 01 Jun 2004 11:18:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BV92c-0006WO-0K for tsvwg-archive@ietf.org; Tue, 01 Jun 2004 09:10:54 -0400 Date: Tue, 01 Jun 2004 09:10:53 -0400 Message-ID: <20040601131053.26555.90278.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: tsvwg-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, tsvwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for tsvwg-archive@ietf.org: List Password // URL ---- -------- tsvwg@ietf.org xeowbe https://www1.ietf.org/mailman/options/tsvwg/tsvwg-archive%40ietf.org From tsvwg-bounces@ietf.org Wed Jun 2 01:45:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29792 for ; Wed, 2 Jun 2004 01:45:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVOYi-0004PS-H9 for tsvwg-archive@ietf.org; Wed, 02 Jun 2004 01:45:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVOWK-0003Vv-00 for tsvwg-archive@ietf.org; Wed, 02 Jun 2004 01:42:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVOUt-0002VR-00; Wed, 02 Jun 2004 01:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVN85-0005mi-DP; Wed, 02 Jun 2004 00:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVKe5-0007YY-LK for tsvwg@megatron.ietf.org; Tue, 01 Jun 2004 21:34:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12540 for ; Tue, 1 Jun 2004 21:34:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVKe3-0005Wt-Qg for tsvwg@ietf.org; Tue, 01 Jun 2004 21:34:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVKd4-00054e-00 for tsvwg@ietf.org; Tue, 01 Jun 2004 21:33:19 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BVKbv-0004AW-00 for tsvwg@ietf.org; Tue, 01 Jun 2004 21:32:07 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i521VQM11108; Tue, 1 Jun 2004 21:31:26 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jun 2004 21:31:26 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64652E3BC3@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: Mpierce1@aol.com, Fil.Dickinson@optus.com.au, tsvwg@ietf.org Subject: RE: [Tsvwg] draft-baker-diffserv-basic-classes-02 Date: Tue, 1 Jun 2004 21:31:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1100336045==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1100336045== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44841.4F344D08" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44841.4F344D08 Content-Type: text/plain; charset="ISO-8859-1" In a message dated May 27, 2004 Mpierce1@aol.com writes: [Mike] I believe this remains as one of the major open questions for the application of SIP or H.323 in a large, managed network. Some comments: I've heard of speech clipping (on answer), but I don't know what "ring-clipping" is. I presume you are referring to call setup delay (or delay to ring). The issue is signaling delay in general (call setup and release), but speech clipping has always been the most serious impact of delay. It seems to me that this issue is really not related to "interfacing to a TDM telephony switch", but occurs equally within a fully IP environment. [Joe] Ring-clipping can occur if SS7 signaling path from the softswitch to the TDM CO is much faster than the signaling path from softswitch to IP gateway that interfaces to the TDM CO were the ringing tone is generated. Speech-clipping can occur if the signaling path from the call answered phone to the softswitch and back to the IP gateway that enables the audio path takes longer then for the person answering the phone to say hello. [Mike] No matter what service class is used for signaling (above, below, or same as speech bearer) there must be guaranteed bandwidth for the expected signaling traffic to provide sufficient low latency and almost zero discard rate independent from the amount of speech bearer traffic. In effect, if signaling is in a separate class and is guaranteed, say 5% of the bandwidth on an outgoing link and speech bearer (EF) is guaranteeed 50%, then it isn't really necessary to think of one being above or below or the same as the other. The forwarding algorithm guarantees a minimum bandwidth to both in what is effectively "time-division multiplexing", but we don't call it that since it is not based on strict timing. The result is that the signaling does not experience "higher latency", but probably has "higher delay variation", mostly due to the varying packet sizes. [Joe] Agree. Putting signaling traffic into a distinct class and engineering that class so that queuing dose not occur does work. In next draft (03) I will total separate telephony signaling from telephony bearer traffic. Regards, Joe Babiarz ------_=_NextPart_001_01C44841.4F344D08 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

In a message = dated May 27, 2004 Mpierce1@aol.com = writes:

[Mike]

I believe this remains as one of = the major open questions for the application of SIP or H.323 in a large, managed = network. Some comments:

I've heard of speech clipping (on answer), but I don't know what "ring-clipping" is. I presume you are referring to call setup = delay (or delay to ring). The issue is signaling delay in general (call setup = and release), but speech clipping has always been the most serious impact = of delay.

It seems to me that this issue is really not related to = "interfacing to a TDM telephony switch", but occurs equally within a fully IP = environment.

[Joe]

Ring-clipping can occur if SS7 = signaling path from the softswitch to the TDM CO is much faster than the signaling = path from softswitch to IP gateway that interfaces to the TDM CO were the ringing tone is = generated. Speech-clipping can occur if the signaling path from the call answered = phone to the softswitch and back to the IP gateway that enables the audio path = takes longer then for the person answering the phone to say hello. =

 

[Mike]

No matter what service class is = used for signaling (above, below, or same as speech bearer) there must be = guaranteed bandwidth for the expected signaling traffic to provide sufficient low = latency and almost zero discard rate independent from the amount of speech = bearer traffic. In effect, if signaling is in a separate class and is = guaranteed, say 5% of the bandwidth on an outgoing link and speech bearer (EF) is = guaranteeed 50%, then it isn't really necessary to think of one being above or = below or the same as the other. The forwarding algorithm guarantees a minimum = bandwidth to both in what is effectively "time-division multiplexing", but = we don't call it that since it is not based on strict timing. The result = is that the signaling does not experience "higher latency", but = probably has "higher delay variation", mostly due to the varying packet = sizes.

[Joe]

Agree. Putting signaling traffic = into a distinct class and engineering that class so that queuing dose not occur does = work. In next draft (03) I will total separate telephony signaling from = telephony bearer traffic.

 

Regards,

Joe Babiarz
=A0

------_=_NextPart_001_01C44841.4F344D08-- --===============1100336045== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1100336045==-- From tsvwg-bounces@ietf.org Wed Jun 2 01:45:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29835 for ; Wed, 2 Jun 2004 01:45:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVOZV-0004t9-HK for tsvwg-archive@ietf.org; Wed, 02 Jun 2004 01:45:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVOXa-0004Hp-00 for tsvwg-archive@ietf.org; Wed, 02 Jun 2004 01:43:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BVOVA-0002jg-00; Wed, 02 Jun 2004 01:41:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVN87-0005pE-Ar; Wed, 02 Jun 2004 00:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVKh3-0000gW-7V for tsvwg@megatron.ietf.org; Tue, 01 Jun 2004 21:37:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12702 for ; Tue, 1 Jun 2004 21:37:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVKh1-0006sk-Lw for tsvwg@ietf.org; Tue, 01 Jun 2004 21:37:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVKgG-0006Rm-00 for tsvwg@ietf.org; Tue, 01 Jun 2004 21:36:37 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BVKfd-0005zk-00 for tsvwg@ietf.org; Tue, 01 Jun 2004 21:35:57 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i521ZNM11334; Tue, 1 Jun 2004 21:35:23 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jun 2004 21:35:23 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64652E3BC4@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: Fil Dickinson , tsvwg@ietf.org Subject: RE: [Tsvwg] draft-baker-diffserv-basic-classes-02 Date: Tue, 1 Jun 2004 21:35:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0173571915==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0173571915== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44841.DBE5BC10" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44841.DBE5BC10 Content-Type: text/plain; charset="ISO-8859-1" In next version 03 of the draft will make the change so that telephony signaling and telephony bearer traffic are in different classes. Thanks for your comments. Regards, Joe. -----Original Message----- From: Fil Dickinson [mailto:Fil.Dickinson@optus.com.au] Sent: Tuesday, May 25, 2004 12:27 AM To: tsvwg@ietf.org Subject: [Tsvwg] draft-baker-diffserv-basic-classes-02 My understanding of this draft is that it proposes the Voice signalling and Voice Bearer are transported in the same class with the exception being "signaling flows between high capacity telephony call servers or soft switches". I am concerned with this. During testing of our multi-vendor converged network I have seen that oversubscribed voice bearer traffic can disrupt the voice signalling traffic which results in abnormal operation of all voice calls [re-registration (outage) of IP Phones]. I would like to see this addressed by a draft that mandates All Voice Signalling and Voice Bearer traffic operate in distinct classes. Ie, a Telephony Signalling Service Class and a Telephony Bearer Service Class. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg ------_=_NextPart_001_01C44841.DBE5BC10 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Tsvwg] draft-baker-diffserv-basic-classes-02

In next version 03 of the draft will make the change = so that telephony signaling and telephony bearer traffic are in = different classes. Thanks for your comments.

Regards, Joe.

-----Original Message-----
From: Fil Dickinson [mailto:Fil.Dickinson@optus.co= m.au]
Sent: Tuesday, May 25, 2004 12:27 AM
To: tsvwg@ietf.org
Subject: [Tsvwg] = draft-baker-diffserv-basic-classes-02

My understanding of this draft is that it proposes = the Voice signalling and
Voice Bearer are transported in the same class with = the exception being
"signaling flows between high capacity = telephony call servers or soft
switches".
I am concerned with this. During testing of our = multi-vendor converged
network I have seen that oversubscribed voice bearer = traffic can disrupt the
voice signalling traffic which results in abnormal = operation of all voice
calls [re-registration (outage) of IP Phones]. I = would like to see this
addressed by a draft that mandates All Voice = Signalling and Voice Bearer
traffic operate in distinct classes. Ie, a Telephony = Signalling Service
Class and a Telephony Bearer Service Class.

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

------_=_NextPart_001_01C44841.DBE5BC10-- --===============0173571915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0173571915==-- From tsvwg-bounces@ietf.org Fri Jun 4 12:47:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21941 for ; Fri, 4 Jun 2004 12:47:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWHrA-0004vT-PS for tsvwg-archive@ietf.org; Fri, 04 Jun 2004 12:47:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWHou-00044k-00 for tsvwg-archive@ietf.org; Fri, 04 Jun 2004 12:45:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BWHmi-00038X-00; Fri, 04 Jun 2004 12:43:12 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BWHXX-00059K-Q9; Fri, 04 Jun 2004 12:27:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWHE0-0008Ah-12; Fri, 04 Jun 2004 12:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWGzX-0005KN-Ts for tsvwg@megatron.ietf.org; Fri, 04 Jun 2004 11:52:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18912 for ; Fri, 4 Jun 2004 11:52:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWGzW-0000fB-Rd for tsvwg@ietf.org; Fri, 04 Jun 2004 11:52:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWGye-0000Ja-00 for tsvwg@ietf.org; Fri, 04 Jun 2004 11:51:28 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BWGxq-0007ks-00 for tsvwg@ietf.org; Fri, 04 Jun 2004 11:50:38 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i54FobG09002 for ; Fri, 4 Jun 2004 17:50:37 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i54Fobg06519 for ; Fri, 4 Jun 2004 17:50:37 +0200 (MEST) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id RAA18116 for ; Fri, 4 Jun 2004 17:50:36 +0200 (MET DST) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Jun 2004 17:50:35 +0200 Message-ID: From: Meyknecht Bernward To: tsvwg@ietf.org Date: Fri, 4 Jun 2004 17:50:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Tsvwg] what is a 'sufficiently' long idle period ? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, in SCTP RFC and Implem. Guide there's a sentence telling me how to initialize the cwnd after a 'sufficiently' long idle period. Does anyone have a proposal what could be a good value for 'sufficiently' ? 5, 10, 20 times RTO ? .... Text from ch. 2.30 / implem. guide: --------- New text: (Section 7.2.1) --------- o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)). --- --- --- And how does this match ch. 2.14 from implem guide, where I'm told to set cwnd to 2*MTU after one RTO, which could be less than the value from above. Does the formula from 2.30 replace the one from 2.14? Text from ch. 2.14 / implem. guide: --------- New text: (Section 7.2.1) --------- o When the association does not transmit data on a given transport address within an RTO, the cwnd of the transport address SHOULD be adjusted to 2*MTU. Maybe someone has some idea... Best regards, Bernward _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sat Jun 5 12:59:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23428 for ; Sat, 5 Jun 2004 12:59:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWeVy-000404-VW for tsvwg-archive@ietf.org; Sat, 05 Jun 2004 12:59:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWeV6-0003iI-00 for tsvwg-archive@ietf.org; Sat, 05 Jun 2004 12:58:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BWeUH-0003H5-00; Sat, 05 Jun 2004 12:57:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWePu-0008F1-VW; Sat, 05 Jun 2004 12:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWeN6-0007mR-WF for tsvwg@megatron.ietf.org; Sat, 05 Jun 2004 12:50:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22966 for ; Sat, 5 Jun 2004 12:50:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWeN5-0001IM-VA for tsvwg@ietf.org; Sat, 05 Jun 2004 12:50:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWeMD-00010W-00 for tsvwg@ietf.org; Sat, 05 Jun 2004 12:49:21 -0400 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BWeLK-0000jN-00; Sat, 05 Jun 2004 12:48:26 -0400 Received: from [192.168.1.15] (p5089EF11.dip.t-dialin.net [80.137.239.17]) by ilsa.franken.de (Postfix) with ESMTP id 03F67245DD; Sat, 5 Jun 2004 18:46:48 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: quoted-printable Message-Id: <27BFFDA1-B710-11D8-BE62-000A95DC192A@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: "'lksctp-developers@lists.sourceforge.net'" , tsvwg@ietf.org, sigtran@ietf.org From: Michael Tuexen Date: Sat, 5 Jun 2004 18:48:22 +0200 X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Registration for 7th SCTP Interop is open and ends at June 18th X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Dear all, the 7th SCTP interop will be held at University of Applied Sciences,=20 M=FCnster, from July 25th to July 30th 2004. Tested specifications include RFC 2960, RFC 3309, RFC 3758, the=20 Implementers Guide, ADD-IP Extension, PKTDRPREP Extension and the SCTP MIB. In addition to the 'usual' setup there will be a Gigabit Ethernet for performance testing. You can register until June 18th and find more information at http://sctp.fh-muenster.de If you have any further questions please do not hesitate to contact me=20= via tuexen@fh-muenster.de Happy SCTPing Michael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Jun 7 15:46:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11630 for ; Mon, 7 Jun 2004 15:46:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXQ4r-00066P-NA for tsvwg-archive@ietf.org; Mon, 07 Jun 2004 15:46:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXQ25-0004RU-00 for tsvwg-archive@ietf.org; Mon, 07 Jun 2004 15:43:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXQ0H-0003iX-01; Mon, 07 Jun 2004 15:41:53 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXPqr-00036r-Il; Mon, 07 Jun 2004 15:32:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXPnp-0000Q4-4q; Mon, 07 Jun 2004 15:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXPff-0006eq-Pd for tsvwg@megatron.ietf.org; Mon, 07 Jun 2004 15:20:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08531 for ; Mon, 7 Jun 2004 15:20:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXPfe-00002S-AE for tsvwg@ietf.org; Mon, 07 Jun 2004 15:20:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXPeQ-0006me-00 for tsvwg@ietf.org; Mon, 07 Jun 2004 15:19:19 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 1BXPcq-000613-00 for tsvwg@ietf.org; Mon, 07 Jun 2004 15:17:40 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.9p1/8.12.8) with ESMTP id i57JHWCS028586; Mon, 7 Jun 2004 12:17:32 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200406071917.i57JHWCS028586@cougar.icir.org> To: tsvwg@ietf.org From: Sally Floyd Date: Mon, 07 Jun 2004 12:17:32 -0700 Cc: Mark Handley , Andrei Gurtov , Jitu Padhye Subject: [Tsvwg] Errata for RFC 3448, "TCP Friendly Rate Control (TFRC)" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a notice that I am sending in an Errata to the RFC Editor for RFC 3448. This is from errata that has been on the TFRC web page for over a year, but that I have never managed to send in the RFC Editor for the "RFC Errata" web page. FYI. - Sally http://www.icir.org/tfrc/ The RFC 3448 Errata: RFC 3448, TCP Friendly Rate Control (TFRC): Protocol Specification Reported By: Joerg Widmer Date: March 4, 2003 * Nofeedback timeout: Correct an inconsistency in the document. In Section 4: "If the sender does not receive a feedback report for two round trip times, it cuts its sending rate in half." Should be: "If the sender does not receive a feedback report for four round trip times, it cuts its sending rate in half." Reported By: Mark Handley, from Wim Heirman Date: March 13, 2003 In Section 4.4, item (2): If the nofeedback timer expires when the sender does not yet have an RTT sample, and has not yet received any feedback from the receiver, Should be: If the nofeedback timer expires when the sender does not yet have an RTT sample, and has not yet received any feedback from the receiver, or when p == 0, Reported By: Sally Floyd, from Michele R. Date: April 29, 2003 * In Section 5.5, when initializing DF, initialize from 0 to n, not from * 1 to n: In Section 5.5: for (i = 1 to n) { DF_i = 1; } Should be: for (i = 0 to n) { DF_i = 1; } _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Jun 8 08:47:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23358 for ; Tue, 8 Jun 2004 08:47:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXg10-0003Os-7G for tsvwg-archive@ietf.org; Tue, 08 Jun 2004 08:47:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXg08-0002eL-00 for tsvwg-archive@ietf.org; Tue, 08 Jun 2004 08:46:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXfzF-0001ow-00; Tue, 08 Jun 2004 08:45:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXfpo-0002y3-EE; Tue, 08 Jun 2004 08:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXflH-0001tj-Ss for tsvwg@megatron.ietf.org; Tue, 08 Jun 2004 08:31:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22638 for ; Tue, 8 Jun 2004 08:31:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXflH-0007IX-AR for tsvwg@ietf.org; Tue, 08 Jun 2004 08:31:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXfkF-0006YI-00 for tsvwg@ietf.org; Tue, 08 Jun 2004 08:30:24 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 1BXfj9-00058V-00 for tsvwg@ietf.org; Tue, 08 Jun 2004 08:29:15 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i58CSdoA025758; Tue, 8 Jun 2004 07:28:41 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <40C5B0DC.8010205@stewart.chicago.il.us> Date: Tue, 08 Jun 2004 07:28:12 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Meyknecht Bernward Subject: Re: [Tsvwg] what is a 'sufficiently' long idle period ? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Bernward: IMO you really do not need to do the cwnd reduction if you are applying a burst limit... this whole reduction thing (I think) needs to be revisited with respect to burst limit and of course how long it takes to degrade the cwnd... R Meyknecht Bernward wrote: >Hi all, > >in SCTP RFC and Implem. Guide there's a sentence telling me how to initialize the >cwnd after a 'sufficiently' long idle period. > >Does anyone have a proposal what could be a good value for 'sufficiently' ? >5, 10, 20 times RTO ? .... > >Text from ch. 2.30 / implem. guide: >--------- New text: (Section 7.2.1) --------- o >The initial cwnd before DATA transmission or after a sufficiently long idle period >MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)). > >--- --- --- > >And how does this match ch. 2.14 from implem guide, where I'm told to set cwnd >to 2*MTU after one RTO, which could be less than the value from above. >Does the formula from 2.30 replace the one from 2.14? > >Text from ch. 2.14 / implem. guide: >--------- New text: (Section 7.2.1) --------- o >When the association does not transmit data on a given transport address within an RTO, >the cwnd of the transport address SHOULD be adjusted to 2*MTU. > >Maybe someone has some idea... > > >Best regards, > >Bernward > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > > -- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Jun 8 09:17:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24916 for ; Tue, 8 Jun 2004 09:17:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXgTx-0001qe-NV for tsvwg-archive@ietf.org; Tue, 08 Jun 2004 09:17:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXgSv-00016y-00 for tsvwg-archive@ietf.org; Tue, 08 Jun 2004 09:16:34 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXgSN-0000Nk-00; Tue, 08 Jun 2004 09:15:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXgLU-0005uz-J7; Tue, 08 Jun 2004 09:08:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXgJt-0005TE-AX for tsvwg@megatron.ietf.org; Tue, 08 Jun 2004 09:07:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24388 for ; Tue, 8 Jun 2004 09:07:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXgJs-0001rR-N9 for tsvwg@ietf.org; Tue, 08 Jun 2004 09:07:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXgIf-0000pP-00 for tsvwg@ietf.org; Tue, 08 Jun 2004 09:05:58 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BXgHX-0007Rm-00 for tsvwg@ietf.org; Tue, 08 Jun 2004 09:04:48 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i58D4iG27089; Tue, 8 Jun 2004 15:04:44 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i58D4gl28408; Tue, 8 Jun 2004 15:04:42 +0200 (MEST) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA03076; Tue, 8 Jun 2004 15:04:39 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Jun 2004 15:04:38 +0200 Message-ID: From: Meyknecht Bernward To: "'Randall R. Stewart (home)'" , tsvwg@ietf.org Subject: AW: [Tsvwg] what is a 'sufficiently' long idle period ? Date: Tue, 8 Jun 2004 15:04:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Randy, thanks for your reply, yes these cwnd reduction things look strange for me in some aspects... As long as my burst limit allows me to send as much data as the actual reduced cwnd would allow, in this case, I would be content with skipping all these cwnd reduction things, and if you set the cwnd to small 2*mtu, this will be the case. Anyhow I don't like the immediate reduction to 2*mtu after a single rto, reduction to min (4*MTU, max (2*MTU, 4380 bytes)) looks more logical to me, and... without having a closer look.. I still like the idea of setting cwnd to cwnd/2 per rto til min (4*MTU, max (2*MTU, 4380 bytes)) is reached. For the case where a big cwnd/2 still allows to send more than my burst limit would allow. Best regards, Bernward -----Ursprungliche Nachricht----- Von: Randall R. Stewart (home) [mailto:randall@stewart.chicago.il.us] Gesendet: Dienstag, 8. Juni 2004 14:28 An: Meyknecht Bernward Cc: tsvwg@ietf.org Betreff: Re: [Tsvwg] what is a 'sufficiently' long idle period ? Bernward: IMO you really do not need to do the cwnd reduction if you are applying a burst limit... this whole reduction thing (I think) needs to be revisited with respect to burst limit and of course how long it takes to degrade the cwnd... R Meyknecht Bernward wrote: >Hi all, > >in SCTP RFC and Implem. Guide there's a sentence telling me how to initialize the >cwnd after a 'sufficiently' long idle period. > >Does anyone have a proposal what could be a good value for 'sufficiently' ? >5, 10, 20 times RTO ? .... > >Text from ch. 2.30 / implem. guide: >--------- New text: (Section 7.2.1) --------- o >The initial cwnd before DATA transmission or after a sufficiently long idle period >MUST be set to min (4*MTU, max (2*MTU, 4380 bytes)). > >--- --- --- > >And how does this match ch. 2.14 from implem guide, where I'm told to set cwnd >to 2*MTU after one RTO, which could be less than the value from above. >Does the formula from 2.30 replace the one from 2.14? > >Text from ch. 2.14 / implem. guide: >--------- New text: (Section 7.2.1) --------- o >When the association does not transmit data on a given transport address within an RTO, >the cwnd of the transport address SHOULD be adjusted to 2*MTU. > >Maybe someone has some idea... > > >Best regards, > >Bernward > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > > -- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Jun 11 09:21:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23752 for ; Fri, 11 Jun 2004 09:21:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYlyf-0003YE-I5 for tsvwg-archive@ietf.org; Fri, 11 Jun 2004 09:21:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYlln-0000es-00 for tsvwg-archive@ietf.org; Fri, 11 Jun 2004 09:08:32 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYlaj-0005hh-00; Fri, 11 Jun 2004 08:57:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkTm-0000sD-Kz; Fri, 11 Jun 2004 07:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYVgx-0000uV-OO; Thu, 10 Jun 2004 15:58:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28033; Thu, 10 Jun 2004 15:58:26 -0400 (EDT) Message-Id: <200406101958.PAA28033@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 10 Jun 2004 15:58:26 -0400 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-addip-sctp-09.txt Pages : 37 Date : 2004-6-10 This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-addip-sctp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-10161836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-addip-sctp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-10161836.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Fri Jun 11 12:42:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16217 for ; Fri, 11 Jun 2004 12:42:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYp6Z-00039P-07 for tsvwg-archive@ietf.org; Fri, 11 Jun 2004 12:42:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYp5B-0002RC-00 for tsvwg-archive@ietf.org; Fri, 11 Jun 2004 12:40:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BYp44-0001bR-00; Fri, 11 Jun 2004 12:39:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYons-0002Ap-7y; Fri, 11 Jun 2004 12:22:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYoUB-00035J-JR for tsvwg@megatron.ietf.org; Fri, 11 Jun 2004 12:02:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13754 for ; Fri, 11 Jun 2004 12:02:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYoUA-0006Oq-Py for tsvwg@ietf.org; Fri, 11 Jun 2004 12:02:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYoTJ-0005sd-00 for tsvwg@ietf.org; Fri, 11 Jun 2004 12:01:38 -0400 Received: from mx4.broadwing.com ([216.140.57.248] helo=ausspam02.ixc-comm.com) by ietf-mx with esmtp (Exim 4.12) id 1BYoST-0005Ia-00; Fri, 11 Jun 2004 12:00:46 -0400 Received: from mail pickup service by ausspam02.ixc-comm.com with Microsoft SMTPSVC; Fri, 11 Jun 2004 10:57:25 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by ausspam02.ixc-comm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Jun 2004 07:57:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkTo-0000sI-E8; Fri, 11 Jun 2004 07:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYVgx-0000uV-OO; Thu, 10 Jun 2004 15:58:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28033; Thu, 10 Jun 2004 15:58:26 -0400 (EDT) Message-Id: <200406101958.PAA28033@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 10 Jun 2004 15:58:26 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 11 Jun 2004 12:57:29.0062 (UTC) FILETIME=[A6DF7860:01C44FB3] Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-09.txt X-BeenThere: tsvwg@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-addip-sctp-09.txt Pages : 37 Date : 2004-6-10 This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-addip-sctp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-10161836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-addip-sctp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-10161836.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Fri Jun 11 13:20:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19376 for ; Fri, 11 Jun 2004 13:20:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYphj-0000OQ-FS for tsvwg-archive@ietf.org; Fri, 11 Jun 2004 13:20:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYpfS-0006wq-00 for tsvwg-archive@ietf.org; Fri, 11 Jun 2004 13:18:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BYpe8-0006GU-00; Fri, 11 Jun 2004 13:16:52 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BYpaS-0004pL-EX; Fri, 11 Jun 2004 13:13:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYpQO-0005Qp-29; Fri, 11 Jun 2004 13:02:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYp8n-0000pg-P3 for tsvwg@megatron.ietf.org; Fri, 11 Jun 2004 12:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16453 for ; Fri, 11 Jun 2004 12:44:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYp8m-0004iJ-UU for tsvwg@ietf.org; Fri, 11 Jun 2004 12:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYp7w-00049S-00 for tsvwg@ietf.org; Fri, 11 Jun 2004 12:43:36 -0400 Received: from mx3.broadwing.com ([216.140.57.247] helo=ausspam01.ixc-comm.com) by ietf-mx with esmtp (Exim 4.12) id 1BYp6Y-0002zj-00; Fri, 11 Jun 2004 12:42:10 -0400 Received: from mail pickup service by ausspam01.ixc-comm.com with Microsoft SMTPSVC; Fri, 11 Jun 2004 11:35:56 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by ausspam01.ixc-comm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Jun 2004 08:11:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkTo-0000sI-E8; Fri, 11 Jun 2004 07:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYVgx-0000uV-OO; Thu, 10 Jun 2004 15:58:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28033; Thu, 10 Jun 2004 15:58:26 -0400 (EDT) Message-Id: <200406101958.PAA28033@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 10 Jun 2004 15:58:26 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 11 Jun 2004 13:11:40.0953 (UTC) FILETIME=[A2A3B890:01C44FB5] Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-09.txt X-BeenThere: tsvwg@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-addip-sctp-09.txt Pages : 37 Date : 2004-6-10 This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-addip-sctp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-10161836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-addip-sctp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-10161836.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Mon Jun 14 10:16:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04492 for ; Mon, 14 Jun 2004 10:16:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZsFu-00048z-0a for tsvwg-archive@ietf.org; Mon, 14 Jun 2004 10:16:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZsF1-0003qi-00 for tsvwg-archive@ietf.org; Mon, 14 Jun 2004 10:15:16 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZsDu-0003Km-00; Mon, 14 Jun 2004 10:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZrzH-0000sX-8q; Mon, 14 Jun 2004 09:58:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZriy-0006gn-NW for tsvwg@megatron.ietf.org; Mon, 14 Jun 2004 09:42:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01876 for ; Mon, 14 Jun 2004 09:42:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZriy-0002VI-1S for tsvwg@ietf.org; Mon, 14 Jun 2004 09:42:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZriE-0002G6-00 for tsvwg@ietf.org; Mon, 14 Jun 2004 09:41:23 -0400 Received: from dmzraw2.extranet.tce.com ([157.254.234.138]) by ietf-mx with esmtp (Exim 4.12) id 1BZrhY-0001wa-00 for tsvwg@ietf.org; Mon, 14 Jun 2004 09:40:40 -0400 Received: from smtprelay.indy.tce.com (ismtprelay.indy.tce.com [157.254.96.114]) by dmzraw2.extranet.tce.com (8.12.5/8.12.5) with ESMTP id i5EDe9G3018415 for ; Mon, 14 Jun 2004 13:40:09 GMT Received: from parexch9.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay.indy.tce.com (8.9.3/8.9.1) with ESMTP id NAA14539 for ; Mon, 14 Jun 2004 13:40:07 GMT Received: by outlook.paris.thmulti.com with Internet Mail Service (5.5.2657.72) id ; Mon, 14 Jun 2004 15:42:54 +0200 Message-ID: <8B094DD77629D31180280008C7F31B810576F627@renexch4.rennes.thmulti.com> From: Straub Gilles To: "'tsvwg@ietf.org'" Date: Mon, 14 Jun 2004 15:39:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Tsvwg] Are IP routers transparent to UDP Lite ? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello All, I am trying to evaluate UDP Lite technique. I had a look to the 2003 draft on this matter. I had a question regarding UDB checksum processing in IP routers : although, in principle a transport layer is processed in end to end (in source and destination), I wanted to check that no CRC check is performed in IP routers : is anybody aware of IP routers where UDP or TCP checksum computation (check & discard) is or can be enabled ? If UDP checksum computation is always done in the host only, then UDP lite applications can be developped on existing internet, otherwise, this would require router modifications. Thanks in advance for any feedback I would get on this topic Best Regards Gilles STRAUB gilles.straub@thomson.net THOMSON _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Jun 14 15:38:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23950 for ; Mon, 14 Jun 2004 15:38:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZxHi-0006sV-Vd for tsvwg-archive@ietf.org; Mon, 14 Jun 2004 15:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZxGn-0006aQ-00 for tsvwg-archive@ietf.org; Mon, 14 Jun 2004 15:37:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BZxFy-00061E-00; Mon, 14 Jun 2004 15:36:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZxBb-0000rs-E1; Mon, 14 Jun 2004 15:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZwzK-0007GB-GH for tsvwg@megatron.ietf.org; Mon, 14 Jun 2004 15:19:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22629 for ; Mon, 14 Jun 2004 15:19:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZwzJ-00017H-5W for tsvwg@ietf.org; Mon, 14 Jun 2004 15:19:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZwyT-0000q1-00 for tsvwg@ietf.org; Mon, 14 Jun 2004 15:18:29 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BZwxm-0000V7-00 for tsvwg@ietf.org; Mon, 14 Jun 2004 15:17:46 -0400 Received: from isi.edu (c2-vpn05.isi.edu [128.9.176.217]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5EJGcJ28922; Mon, 14 Jun 2004 12:16:38 -0700 (PDT) Message-ID: <40CDF999.6020901@isi.edu> Date: Mon, 14 Jun 2004 12:16:41 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Straub Gilles Subject: Re: [Tsvwg] Are IP routers transparent to UDP Lite ? References: <8B094DD77629D31180280008C7F31B810576F627@renexch4.rennes.thmulti.com> In-Reply-To: <8B094DD77629D31180280008C7F31B810576F627@renexch4.rennes.thmulti.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tsvwg@ietf.org'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0444469765==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0444469765== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8A81A25C47EDBA482C86586D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8A81A25C47EDBA482C86586D Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Straub Gilles wrote: > Hello All, > > > I am trying to evaluate UDP Lite technique. I had a look to the 2003 draft > on this matter. > I had a question regarding UDB checksum processing in IP routers : although, > in principle a transport layer is processed in end to end (in source and > destination), I wanted to check that no CRC check is performed in IP routers > : is anybody aware of IP routers where UDP or TCP checksum computation > (check & discard) is or can be enabled ? That would kill IPsec'd packets... a protection that would defeat IPsec isn't very protective ;-( > If UDP checksum computation is always done in the host only, then UDP lite > applications can be developped on existing internet, otherwise, this would > require router modifications. Any router that performed that sort of delayed fill-in or check is basically performing as a host anyway. It would need to be updated as any host would, if the transport protocols supported changed. Joe > Thanks in advance for any feedback I would get on this topic > > Best Regards > > > Gilles STRAUB > gilles.straub@thomson.net > THOMSON > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --------------enig8A81A25C47EDBA482C86586D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAzfmZE5f5cImnZrsRAlKiAKCPzkXicP9X61oi9DKC6EAxecbKzgCgu4bi 1VuqHHaQc7zzhMmX04zbQe8= =QNwH -----END PGP SIGNATURE----- --------------enig8A81A25C47EDBA482C86586D-- --===============0444469765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0444469765==-- From tsvwg-bounces@ietf.org Mon Jun 14 18:42:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09338 for ; Mon, 14 Jun 2004 18:42:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba0A0-0003hX-Ps for tsvwg-archive@ietf.org; Mon, 14 Jun 2004 18:42:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba07Y-0002nS-00 for tsvwg-archive@ietf.org; Mon, 14 Jun 2004 18:40:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ba04t-0001tm-00; Mon, 14 Jun 2004 18:37:19 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ba04t-0001eM-LT; Mon, 14 Jun 2004 18:37:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZz9n-0000oB-1h; Mon, 14 Jun 2004 17:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZxJZ-0003Pq-U2 for tsvwg@megatron.ietf.org; Mon, 14 Jun 2004 15:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24032 for ; Mon, 14 Jun 2004 15:40:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZxJY-0007TL-Iw for tsvwg@ietf.org; Mon, 14 Jun 2004 15:40:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZxIW-00079o-00 for tsvwg@ietf.org; Mon, 14 Jun 2004 15:39:13 -0400 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BZxHT-0006ck-00; Mon, 14 Jun 2004 15:38:07 -0400 Received: from [192.168.1.15] (p5089DC13.dip.t-dialin.net [80.137.220.19]) by ilsa.franken.de (Postfix) with ESMTP id DA02D2465B; Mon, 14 Jun 2004 21:36:12 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: quoted-printable Message-Id: <5859018C-BE3A-11D8-BA69-000A95DC192A@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: "'lksctp-developers@lists.sourceforge.net'" , tsvwg@ietf.org, sigtran@ietf.org From: Michael Tuexen Date: Mon, 14 Jun 2004 21:38:00 +0200 X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Registration for 7th SCTP Interop ends at June 18th X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Dear all, the 7th SCTP interop will be held at University of Applied Sciences,=20 M=FCnster, from July 25th to July 30th 2004. Tested specifications include RFC 2960, RFC 3309, RFC 3758, the=20 Implementers Guide, ADD-IP Extension, PKTDRPREP Extension and the SCTP MIB. In addition to the 'usual' setup there will be a Gigabit Ethernet for performance testing. You can register until June 18th and find more information at http://sctp.fh-muenster.de If you have any further questions please do not hesitate to contact me=20= via tuexen@fh-muenster.de Happy SCTPing Michael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Jun 16 01:23:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25673 for ; Wed, 16 Jun 2004 01:23:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaStL-0005nW-Ba for tsvwg-archive@ietf.org; Wed, 16 Jun 2004 01:23:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaP2v-0001mV-00 for tsvwg-archive@ietf.org; Tue, 15 Jun 2004 21:16:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BaLWc-0007j3-00; Tue, 15 Jun 2004 17:31:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaLOw-0005dI-Nw; Tue, 15 Jun 2004 17:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaL8r-0000Ki-Ku for tsvwg@megatron.ietf.org; Tue, 15 Jun 2004 17:06:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16531 for ; Tue, 15 Jun 2004 17:06:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaL8q-0004sZ-Ag for tsvwg@ietf.org; Tue, 15 Jun 2004 17:06:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaJlx-0002kx-00 for tsvwg@ietf.org; Tue, 15 Jun 2004 15:39:06 -0400 Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 1BaJ7s-00058k-00 for tsvwg@ietf.org; Tue, 15 Jun 2004 14:57:40 -0400 Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i5FIuXVY028373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 15 Jun 2004 19:56:33 +0100 (BST) Message-ID: <40CF4662.9090101@erg.abdn.ac.uk> Date: Tue, 15 Jun 2004 19:56:34 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] Are IP routers transparent to UDP Lite ? References: <8B094DD77629D31180280008C7F31B810576F627@renexch4.rennes.thmulti.com> In-Reply-To: <8B094DD77629D31180280008C7F31B810576F627@renexch4.rennes.thmulti.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-ERG-MailScanner-To: tsvwg@ietf.org Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Two devices that do recompute transport checksums are: Network Address Translation (NAT) Midboxes and gateways that do some sort of connection splitting I don't count these as IP routers, although these functions can be performed on router hardware platforms... Note that UDP-Lite has a different IP protocol type, so these devices will anyway treat the IP packets carrying UDP-Lite in a different manner to that of TCP, UDP, etc. A "normal" router should pass transport checksums as-is. Gorry Dairhurst Straub Gilles wrote: > Hello All, > > > I am trying to evaluate UDP Lite technique. I had a look to the 2003 draft > on this matter. > I had a question regarding UDB checksum processing in IP routers : although, > in principle a transport layer is processed in end to end (in source and > destination), I wanted to check that no CRC check is performed in IP routers > : is anybody aware of IP routers where UDP or TCP checksum computation > (check & discard) is or can be enabled ? > > If UDP checksum computation is always done in the host only, then UDP lite > applications can be developped on existing internet, otherwise, this would > require router modifications. > Thanks in advance for any feedback I would get on this topic > > Best Regards > > > Gilles STRAUB > gilles.straub@thomson.net > THOMSON > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Jun 17 01:01:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16162 for ; Thu, 17 Jun 2004 01:01:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bap1E-0005GK-AF for tsvwg-archive@ietf.org; Thu, 17 Jun 2004 01:00:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Baoyf-0004j6-00 for tsvwg-archive@ietf.org; Thu, 17 Jun 2004 00:58:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Baoxv-0004Nl-00; Thu, 17 Jun 2004 00:57:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaooU-0001xN-QP; Thu, 17 Jun 2004 00:47:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaoeG-0008DW-N6 for tsvwg@megatron.ietf.org; Thu, 17 Jun 2004 00:37:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15370 for ; Thu, 17 Jun 2004 00:37:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaoeC-0005jd-2B for tsvwg@ietf.org; Thu, 17 Jun 2004 00:37:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaodC-0005Or-00 for tsvwg@ietf.org; Thu, 17 Jun 2004 00:36:07 -0400 Received: from [202.108.44.204] (helo=163.com) by ietf-mx with smtp (Exim 4.12) id 1BaocF-00052R-00; Thu, 17 Jun 2004 00:35:07 -0400 Received: from CeMNet-GS28 (unknown [155.69.103.82]) by 192.168.1.204 (Coremail) with SMTP id KBQEAGwf0UAHAGdS.1 for ; Thu, 17 Jun 2004 12:34:56 +0800 (CST) X-Originating-IP: [155.69.103.82] Date: Thu, 17 Jun 2004 12:35:59 +0800 From: "Lv Qian" To: "tcpm" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: Content-Transfer-Encoding: 7bit Cc: tsvwg Subject: [Tsvwg] Inquire problem about TFRC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit tcpmHi, all, I met a problem when doing simulation on TFRC these days. I am using ns-2.26, Redhat 9.0, and all NS2 valication tests are passed. I want to test the friendliness among some TFRC flows in the bottleneck link. The topology is very simple(the parameters such as bandwidth, queue is listed in the script below). s0 k0 | | s1 --- r1 ------ r2 --- k1 | | s2 k2 However, when I use awk to get the throughput data of each flow, I found that when time < 300, the simulation result is satisfactory; however, when time >300, one flow increases abruptly while other flows descend to nearly zero. This is abnormal. I tested other scripts, including the test-suite-friendly.tcl/two-friendly script in ns-2.26/tcl/test. When I changed the relevant bandwidth parameters and simulation time to nearly 1000s, I got the similar result. The tfrcsim.tcl script is as follows: ######################################################## set flows 4 set queue RED set rate 15 #set ecn 1 set ecn 0 set discount 0 set ns [new Simulator] proc stop {} { global ns s1_tf $ns flush-trace close $s1_tf exit 0 } set node_(r1) [$ns node] set node_(r2) [$ns node] Queue/RED set gentle_ true if {$ecn==1} { Queue/RED set setbit_ true Agent/TCP set ecn_ 1 } $ns duplex-link $node_(r1) $node_(r2) [set rate]Mb 20ms $queue $ns queue-limit $node_(r1) $node_(r2) 50 $ns queue-limit $node_(r2) $node_(r1) 50 Agent/TFRC set packetSize_ 1000 Agent/TFRCSink set discount_ $discount Agent/TFRCSink set printLoss_ 1 Agent/TFRCSink set smooth_ 1 Agent/TFRC set printStatus_ 0 Agent/TFRC set df_ 0.95 Agent/TFRC set ca_ 1 for {set i 0} {$i < 3} {incr i} { set node_(s$i) [$ns node] set node_(k$i) [$ns node] $ns duplex-link $node_(s$i) $node_(r1) 100Mb 2ms DropTail $ns duplex-link $node_(k$i) $node_(r2) 100Mb 2ms DropTail set tf$i [$ns create-connection TFRC $node_(s$i) TFRCSink $node_(k$i) 0] set sec [expr $i/10] set frac [expr $i%10] set starttime $sec.$frac $ns at $starttime "[set tf$i] start" $ns at 1000 "[set tf$i] stop" } set s1_tf [open out.tr w] $ns trace-queue $node_(r1) $node_(r2) $s1_tf $ns at 1005 "stop" $ns run ###################################################### Is there something wrong in my script? Or is there some bugs in the TFRC code in NS2? I am suffered for this problem these days. Can any one help me to solve it? Thank you! Regards, Lv Qian (SCE, NTU) 2004-06-17 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Jun 17 17:30:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17080 for ; Thu, 17 Jun 2004 17:30:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb4Sn-0003fb-6b for tsvwg-archive@ietf.org; Thu, 17 Jun 2004 17:30:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb4Ro-0003LG-00 for tsvwg-archive@ietf.org; Thu, 17 Jun 2004 17:29:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bb4R7-000310-00; Thu, 17 Jun 2004 17:28:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bb4R7-00034w-Kc; Thu, 17 Jun 2004 17:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb4Ho-0001ty-Ri; Thu, 17 Jun 2004 17:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3tw-000487-AW for tsvwg@megatron.ietf.org; Thu, 17 Jun 2004 16:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15258 for ; Thu, 17 Jun 2004 16:54:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb3tu-0007ln-UD for tsvwg@ietf.org; Thu, 17 Jun 2004 16:54:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb3su-0007O6-00 for tsvwg@ietf.org; Thu, 17 Jun 2004 16:53:21 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 1Bb3qp-0006dx-00; Thu, 17 Jun 2004 16:51:11 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.9p1/8.12.8) with ESMTP id i5HKp9CS000589; Thu, 17 Jun 2004 13:51:09 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200406172051.i5HKp9CS000589@cougar.icir.org> To: "Lv Qian" From: Sally Floyd Date: Thu, 17 Jun 2004 13:51:09 -0700 Cc: tcpm , tsvwg Subject: [Tsvwg] Re: [tcpm] Inquire problem about TFRC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a classic case of phase effects. You could look at the 1992 paper "On Traffic Phase Effects in Packet-Switched Gateways", available from "http://www.icir.org/floyd/papers.html". One solution is to add some randomization in the form of "overhead_", which dithers TFRC's outgoing packets: Agent/TFRC set overhead_ 1 >From tfrc.cc: next = size_/xrate; // // randomize between next*(1 +/- overhead_) // next = next*(2*overhead_*Random::uniform()-overhead_+1); Other solutions are to use more realistic scenarios, including competing TCP traffic, with some web traffic, and reverse-path traffic (to include small Ack packets in the forward path). I am enclosing a modified script below. Instead of using a long trace file, I modified the script to have NS print out the packet information that was wanted. The results can be displayed as follows: ./ns tfrcsim.tcl > data awk '{if ($4==0) {print $2, $6;}}' data > data.0 awk '{if ($4==1) {print $2, $6;}}' data > data.1 awk '{if ($4==2) {print $2, $6;}}' data > data.2 xgraph -bb -tk -x time -y packets data.0 data.1 data.2 & There is still a brief period with phase effects, but it is much more moderate than before. You also might be interested in the paper "Internet Research Needs Better Models", available from "http://www.icir.org/models/bettermodels.html. - Sally http://www.icir.org/floyd/ ==================================================================== tfrcsim.tcl (the modified version) ==================================================================== set flows 4 set queue RED set rate 15 #set ecn 1 set ecn 0 set discount 0 set ns [new Simulator] proc stop {} { global ns exit 0 } proc printpkts { time flowid flow } { puts "time $time tfrc $flowid data_pkts_sent [$flow set ndatapack_]" } set node_(r1) [$ns node] set node_(r2) [$ns node] Queue/RED set gentle_ true if {$ecn==1} { Queue/RED set setbit_ true Agent/TCP set ecn_ 1 } $ns duplex-link $node_(r1) $node_(r2) [set rate]Mb 20ms $queue $ns queue-limit $node_(r1) $node_(r2) 50 $ns queue-limit $node_(r2) $node_(r1) 50 Agent/TFRC set packetSize_ 1000 Agent/TFRCSink set discount_ $discount #Agent/TFRCSink set printLoss_ 1 Agent/TFRCSink set printLoss_ 0 Agent/TFRCSink set smooth_ 1 Agent/TFRC set printStatus_ 0 Agent/TFRC set df_ 0.95 Agent/TFRC set ca_ 1 #Agent/TFRC set overhead_ 0 Agent/TFRC set overhead_ 1 for {set i 0} {$i < 3} {incr i} { set node_(s$i) [$ns node] set node_(k$i) [$ns node] $ns duplex-link $node_(s$i) $node_(r1) 100Mb 2ms DropTail $ns duplex-link $node_(k$i) $node_(r2) 100Mb 2ms DropTail set tf$i [$ns create-connection TFRC $node_(s$i) TFRCSink $node_(k$i) 0] set sec [expr $i/10] set frac [expr $i%10] set starttime $sec.$frac $ns at $starttime "[set tf$i] start" for {set time 0} {$time <= 1000} {incr time} { $ns at $time "printpkts $time $i [set tf$i]" } $ns at 1000 "[set tf$i] stop" } $ns at 1005 "stop" $ns run _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Jun 24 23:18:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17676 for ; Thu, 24 Jun 2004 23:18:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdhEt-0006Ul-QB for tsvwg-archive@ietf.org; Thu, 24 Jun 2004 23:18:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdhDy-00068y-00 for tsvwg-archive@ietf.org; Thu, 24 Jun 2004 23:17:58 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdhCy-0005Ul-00; Thu, 24 Jun 2004 23:16:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdh43-00089v-3l; Thu, 24 Jun 2004 23:07:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdghz-0003Rk-3j for tsvwg@megatron.ietf.org; Thu, 24 Jun 2004 22:44:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16110 for ; Thu, 24 Jun 2004 22:44:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdghx-0003Eb-9V for tsvwg@ietf.org; Thu, 24 Jun 2004 22:44:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdgh3-0002uB-00 for tsvwg@ietf.org; Thu, 24 Jun 2004 22:43:58 -0400 Received: from [202.108.44.204] (helo=163.com) by ietf-mx with smtp (Exim 4.12) id 1BdggX-0002ZR-00; Thu, 24 Jun 2004 22:43:25 -0400 Received: from CeMNet-GS28 (unknown [155.69.103.82]) by 192.168.1.204 (Coremail) with SMTP id iwBntiiR20AQAGdS.1 for ; Fri, 25 Jun 2004 10:42:58 +0800 (CST) X-Originating-IP: [155.69.103.82] Date: Fri, 25 Jun 2004 10:44:04 +0800 From: "Lv Qian" To: "tcpm" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: Cc: tsvwg Subject: [Tsvwg] Inquire the problem of TFRC in wireless environment X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0068174372==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 --===============0068174372== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQogICAgSGkhDQogICAgSSBhbSBzdHVkeWluZyBURlJDIHRoZXNlIGRheXMsIGFu ZCBJIHdhbnQgdG8gaW5xdWlyZSBzb21lIHByb2JsZW1zIG9uIFRGUkMgaW4gd2lyZWxlc3MgZW52 aXJvbm1lbnQuDQogICAgVEZSQyBpcyBiYXNlZCBvbiB0aGUgVENQIHRocm91Z2hwdXQgZXF1YXRp b24sIHdoaWNoIGlzIGRlZHVjZWQgZnJvbSBSZW5vIFRDUCBtb2RlbCBbUEZUSzk4XS4gSSBub3Rp Y2VkIHRoYXQgaW4gdGhpcyBwYXBlciwgdGhlIGFzc3VtcHRpb24gb24gcGFja2V0IGxvc3MgY2Fu IGJlIHN1bW1hcml6ZWQgYXMgZm9sbG93czogICANCiAgIKGkUGFja2V0IGlzIGxvc3QgaW4gYSBy b3VuZCBpbmRlcGVuZGVudGx5IG9mIGFueSBwYWNrZXRzIGxvc3QgaW4gb3RoZXIgcm91bmRzLiAN CiAgIKGkUGFja2V0IGxvc3NlcyBhcmUgY29ycmVsYXRlZCBhbW9uZyB0aGUgYmFjay10by1iYWNr IHRyYW5zbWlzc2lvbnMgd2l0aGluIGEgcm91bmQgc28gaWYgYSBwYWNrZXQgaXMgbG9zdCwgYWxs IHJlbWFpbmluZyBwYWNrZXRzIHRyYW5zbWl0dGVkIHVudGlsIHRoZSBlbmQgb2YgdGhhdCByb3Vu ZCBhcmUgYWxzbyBsb3N0LiAoSXQgYXNzdW1lcyB0aGF0IHRoZSByb3V0ZXIgdXNlcyBEcm9wVGFp bCBwb2xpY3kpLg0KDQoNClF1ZXN0aW9uczogIA0KICAgICgxKSBEb2VzIHRoZSBUQ1AgdGhyb3Vn aHB1dCBlcXVhdGlvbiBhc3N1bWUgdGhhdCB0aGUgcGFja2V0IGxvc3NlcyBhcmUgY2F1c2VkIG9u bHkgYnkgY29uZ2VzdGlvbj8gT3IgZG9lcyB0aGUgZXF1YXRpb24gY29uc2lkZXJzIGJvdGggdGhl IGNvbmdlc3Rpb24gbG9zcyBhbmQgbm9uLWNvbmdlc3Rpb24gbG9zcyBpZiBvbmx5IHRoZSBsb3Nz IG1lZXQgdGhlIHR3byBhc3N1bXB0aW9ucyBhYm92ZT8NCiAgICAoMikgVEZSQyBjYW4gY2xvc2Vs eSBtb2RlbHMgdGhlIG1lY2hhbmlzbSB1c2VkIGJ5IG1vc3QgVENQIHZhcmlhbnRzLCBpbmNsdWRp bmcgVGFob2UsU2FjayxOZXdSZW5vLFJlbm8oPyksIGFuZCBURlJDIGNhbiBzdXBwb3J0IGJvdGgg UkVEIHJvdXRlciBhbmQgRHJvcFRhaWwgcm91dGVyLiBUaGlzIGlzIGJlY2F1c2UgVEZSQyB1c2Ug bG9zcyBldmVudCBmcmFjdGlvbiB0byBtZWFzdWUgcGFja2V0IGxvc3MgW0ZIUFcwMF0uIFRoZW4s IGRvZXMgdGhpcyBtZWFuIHRoYXQgaW4gVEZSQywgdGhlIGFzc3VtcHRpb25zIGFib3ZlIGNhbiBi ZSB3ZWFrZW5lZD8gSWYgc28sIHdoYXQgaXMgdGhlIGFzc3VtcHRpb24gYWJvdXQgdGhlIHBhY2tl dCBsb3NzIGluIFRGUkM/DQogICAgKDMpIElmIHRoZSBwYWNrZXQgbG9zcyBhcmUgY2F1c2VkIGJ5 IG5vbi1jb25nZXN0aW9uIHJlYXNvbnMsIGlzIFRGUkMgc3RpbGwgYXBwbGljYWJsZT8gRm9yIGV4 YW1wbGUsIGluIGVycm9yLXByb25lIHdpcmVsZXNzIGVudmlyb25tZW50LCB0aGUgcGFja2V0IGxv c3MgbWF5YmUgY2F1c2VkIGJ5IGJpdCBlcnJvci4gVGhlbiwgZ2l2ZW4gdGhhdCBib3RoIFRGUkMg YW5kIFRDUCBjYW5ub3QgZGlmZmVyZW50aWF0ZSB0aGUgd2lyZWxlc3MgbG9zcyBhbmQgY29uZ2Vz dGlvbiBsb3NzLCBpcyBURlJDIHN0aWxsIGZyaWVuZGx5IHRvIFRDUD8gDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpSZWZl cmVuY2U6DQpbUEZUSzk4XSBKLiBQYWRoeWUsIFYuIEZpcm9pdSwgRC4gVG93c2xleSwgYW5kIEou IEt1cm9zZSwgobBNb2RlbGluZyBUQ1AgVGhyb3VnaHB1dDogQSBzaW1wbGUgTW9kZWwgYW5kIGl0 cyBFbXBpcmljYWwgVmFsaWRhdGlvbiyhsSBJbiBQcm9jZWVkaW5ncyBvZiBBQ00gU0lHQ09NTSAx OTk4LCBWYW5jb3V2ZXIsIENhbmFkYSwgU2VwLiAxOTk4Lg0KW0ZIUFcwMF0gUy5GbG95ZCwgTS5I YW5kbGV5LCBKLlBhZGh5ZSwgYW5kIEouV2lkbWVyLCChsEVxdWF0aW9uLUJhc2VkIENvbmdlc3Rp b24gQ29udHJvbCBmb3IgVW5pY2FzdCBBcHBsaWNhdGlvbnM6IHRoZSBFeHRlbmRlZCBWZXJzaW9u obEsIEludGVybmF0aW9uYWwgQ29tcHV0ZXIgU2NpZW5jZSBJbnN0aXR1dGUgdGVjaCByZXBvcnQg VFItMDAtMDMsIE1hcmNoIDIwMDAuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KUmVnYXJkcywNCkx2IFFpYW4gDQpT Y2hvb2wgb2YgQ29tcHV0ZXIgRW5naW5lZXJpbmcsDQpOYW55YW5nIFRlY2hub2xvZ2ljYWwgVW5p dmVyc2l0eQ0KDQoNCg0KDQo= --===============0068174372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0068174372==--