From daemon@optimus.ietf.org Tue Jan 1 01:42:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13659 for ; Tue, 1 Jan 2002 01:42:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA23847 for tsvwg-archive@odin.ietf.org; Tue, 1 Jan 2002 01:42:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23346; Tue, 1 Jan 2002 01:21:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23317 for ; Tue, 1 Jan 2002 01:21:26 -0500 (EST) Received: from localhost ([211.179.220.189]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13536 for ; Tue, 1 Jan 2002 01:21:24 -0500 (EST) Message-Id: <200201010621.BAA13536@ietf.org> Reply-To: sago8572@hananet.net From: 안성철 To: tsvwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 1 Jan 2002 15:21:23 +0900 Subject: [Tsvwg] 아느냐 모르느냐에 따라 천지차이![광고] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org autoinad 님의 한미르 홈페이지

사전 양해 없이 메일 드린 점 사과드립니다.

불필요한 메일이라면 바로 삭제하여 주시기 바랍니다.[소리첨부]

교통사고 보상상담

주먹보다 아는 것이 힘 !

- 보험보상은 일관성이 없어 고무줄 처럼 되기도 합니다.

- 아느냐 모르냐에 따라 보상금은 천지 차이 !!

- 귀하에게 힘이 되어 드리겠습니다.

이럴땐 꼭, 전화 하세요 !

-.교통사고로 당황스러울 때.

-.나의 보상금이 어느 정도인지 알고 싶을 때.

-.보상금이 적다고 느낄 때.

-.빨리 합의하자고 할 때.

-.과실적용이 부당하다고 느낄 때.

-.나의 소득을 인정받지 못할 때.

-.기타 보상관련 궁금 모든 사항.

약속 합니다.

- 전문가와 1대1 실시간 상담

- 신속하고 , 빠른 답변

- 시원한 해결

교통사고 보상상담 [060-700-2114]

본 메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.

더 이상 메일을 수신하고 싶지 않으시면 [수신 거부]라는 메시지를 보내주시면 다시는 발송하지 않도록 주의하겠습니다.

_______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@ns.ietf.org Wed Jan 2 17:03:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11879 for ; Wed, 2 Jan 2002 17:03:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24379 for tsvwg-archive@odin.ietf.org; Wed, 2 Jan 2002 17:03:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23155; Wed, 2 Jan 2002 16:37:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23121 for ; Wed, 2 Jan 2002 16:37:32 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11298 for ; Wed, 2 Jan 2002 16:37:28 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g02LbdQ00321 for ; Wed, 2 Jan 2002 15:37:39 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Jan 2002 15:37:30 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Jan 2002 15:36:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Tsvwg] sctpsocket-02.txt Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 2 Jan 2002 13:36:30 -0800 Message-ID: Thread-Topic: [Tsvwg] sctpsocket-02.txt Thread-Index: AcGSCyF6cdaslP37EdWxMQAIx6TWeAByjLNw From: "Kimble Scott (NET/MtView)" To: "'ext Randall Stewart'" , "Scott Kimble" Cc: X-OriginalArrivalTime: 02 Jan 2002 21:36:28.0901 (UTC) FILETIME=[899A9150:01C193D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA23122 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 8bit Randall, This sounds good. Again, I was not thinking in terms of addip-sctp. -----Original Message----- From: ext Randall Stewart [mailto:randall@stewart.chicago.il.us] Sent: Monday, December 31, 2001 6:54 AM To: Scott Kimble Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] sctpsocket-02.txt Scott: In thinking on this item, I will add a note that if you set the associ_id field to 0 you get the endpoints currently bound set. You must still have a way to get the specific set on a association since if you do NOT have the add-ip draft in place it is possible that if I do a bind to INADDR_ANY and setup an association followed by a ifconfig up of a new address and a subsequent association the same endpoint will have two different associations with different sets of bound addresses. Even if add-ip is supported the peer may NOT support it and so you may get divergent sets of address for the local endpoint... R Scott Kimble wrote: > > Section 8.5 sctp_getladdrs() > > The "sctp_assoc_t id" parameter is not required. Applications may query > an SCTP instance prior to any association being established. > > For example, since IN[6]ADDR_ANY is "optimal" (not necessarily all), an > application my want to call sctp_getladdrs() after calling bind > (IN[6]ADDR_ANY) to determine what the optimal set is. > > -- > Scott.Kimble@NOKIA.com > Office 1.650.864.6587 > Mobile 1.650.743.7903 > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@ns.ietf.org Wed Jan 2 19:21:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13246 for ; Wed, 2 Jan 2002 19:21:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27620 for tsvwg-archive@odin.ietf.org; Wed, 2 Jan 2002 19:21:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26968; Wed, 2 Jan 2002 18:59:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26939 for ; Wed, 2 Jan 2002 18:59:28 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13099 for ; Wed, 2 Jan 2002 18:59:27 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0300pQ25353 for ; Wed, 2 Jan 2002 18:00:51 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Jan 2002 17:59:27 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Jan 2002 17:59:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Tsvwg] Section 4.3.1 sctpsocket-02.txt Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 2 Jan 2002 15:59:06 -0800 Message-ID: Thread-Topic: [Tsvwg] Section 4.3.1 sctpsocket-02.txt Thread-Index: AcGSCjKw9bPvuv35EdWJXQAIx6TWpQBzndXA From: "Kimble Scott (NET/MtView)" To: "'ext Randall Stewart'" , "Scott Kimble" Cc: X-OriginalArrivalTime: 02 Jan 2002 23:59:04.0812 (UTC) FILETIME=[7552FAC0:01C193E9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA26940 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 8bit Here is some additional information on the backlog value. I could not locate a POSIX standard for listen(2). The proposed meaning of a backlog value of 0 is reasonable. However, the protocol layer would now be responsible for something that has traditionally been handled by the "socket layer". Why not use a negative value like the UNIX 98 standard suggests? The UNIX 98 standard states that a backlog value less than 0 will set the socket's listen queue to 0. See http://www.opengroup.org/pubs/catalog/t912.htm sonewconn() was designed with a "fudge factor" such that listen(fd, 0) will allow at least one connection. See "TCP Illustrated Volume 2", p 463, or the description of sonewconn(). FreeBSD-4.2, NetBSD use the "fudge factor" algorithm. Linux-2.2.12 sets a backlog value of 0 to 1. And does not use the "fudge factor". Solais ??? HP-UX ??? -----Original Message----- From: ext Randall Stewart [mailto:randall@stewart.chicago.il.us] Sent: Monday, December 31, 2001 6:47 AM To: Scott Kimble Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Section 4.3.1 sctpsocket-02.txt Scott: After some inter-author discussion. My co-authors feel that the zero back-log is not specified in posix to have any meaning. In other words it is an implementation choice. As such different platforms do different things with a zero backlog... Thus they wanted to use this feature as a way to turn off accepting connections. I have no qualms about instead adding another socket option that enables/disables connections.. this is how it originally was laid out... If you can convince my co-authors we can do this.. but for now I will leave it as is :> R Scott Kimble wrote: > > I may have missed the discussion on this issue. > > Section 4.3.1 defines new meaning to a zero valued backlog parameter to > listen(). > > Historically, when the backlog parameter of listen() is zero, at least > one connection may be established. > > Is it really the intention of the SCTP Socket API's draft to change the > meaning of the backlog parameter when it is zero? > > -- > Scott.Kimble@NOKIA.com > Office 1.650.864.6587 > Mobile 1.650.743.7903 > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Sat Jan 5 13:32:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06433 for ; Sat, 5 Jan 2002 13:32:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17481 for tsvwg-archive@odin.ietf.org; Sat, 5 Jan 2002 13:32:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15617; Sat, 5 Jan 2002 12:10:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15588 for ; Sat, 5 Jan 2002 12:10:22 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05884 for ; Sat, 5 Jan 2002 12:10:18 -0500 (EST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g05H9pJ27528 for ; Sat, 5 Jan 2002 09:09:51 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAQ83980; Sat, 5 Jan 2002 09:09:50 -0800 (PST) Message-ID: <3C37335D.58F85299@stewart.chicago.il.us> Date: Sat, 05 Jan 2002 11:09:49 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: TSV WG list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Submitted the long awaited c-sum draft Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Dear all: I have just sent in the long awaited update to the checksum draft. This includes new code to generate the agreed upon checksum (CRC32c) and touch ups in the wording as well. It should be out within the next few days.. It will be -01 I believe. Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Sun Jan 6 07:15:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22889 for ; Sun, 6 Jan 2002 07:15:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20535 for tsvwg-archive@odin.ietf.org; Sun, 6 Jan 2002 07:15:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19937; Sun, 6 Jan 2002 06:57:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19906 for ; Sun, 6 Jan 2002 06:57:31 -0500 (EST) Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.130.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22806 for ; Sun, 6 Jan 2002 06:57:27 -0500 (EST) Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:2130 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Sun, 6 Jan 2002 13:57:18 +0200 Message-ID: <038101c196a9$45f7ed40$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "sanjay kaniyar" , Cc: References: Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Date: Sun, 6 Jan 2002 13:57:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Sanjay- A number of conerns were raised with such approach. First, it leads to frequent repacketization of data segment as follows. Original segments sent without the timestamp option each carry MSS bytes of data. After RTO, segments have the timestamp option which occupies 12 bytes leaving less space for data. Consequently, the sequence of retransmitted segments will be different than of original segments. In principle, this type of behavior is legal and used by BSD systems. However, there are probably some TCPs and PEPs around that cannot handle it well. Thus, 'be conservative in what you send' approach may apply here. The other concern is that the detection may be less robust in presense of lost segments and ACKs. The timestamp overhead is not that big for large MTU (0.8% for 1500 B) and ROHC is expected to compress TCP options. Additionally, there is some evidence that timing every segment with timestamps is good on bandwidth-limited paths. Based on these considerations, the current understanding is to include timestamps in every segment. Andrei ----- Original Message ----- From: "sanjay kaniyar" To: Cc: Sent: Tuesday, January 01, 2002 12:53 AM Subject: [Tsvwg] Eifel draft and usage of time-stamps. > I have seen the spurious retransmission problem occur in my experiments with > GPRS networks. The frequency of occurrence seems to be quite small though, > about once or twice during the transmission of a 500 K Bytes file with an > MSS of 1500 bytes. Ofcourse, I agree that this frequency could vary with > different networks. In this case, however, incurring 12 bytes of overhead in > every segment and acknowledgemnt seems quite a bit. > > Since it is not necessary to timestamp every segment and acknowledgement > when timestamp option is enabled on a connection, we could do it only when > it is necessary. It is the sender which determines when this is necessary, > and the following approach is backwards compatible in the sense that a > sender taking this approach would work properly with a receiver adhering to > the traditional time-stamping approach and vice-versa. > > Sender-TCP would put a timestamp in a segment if: > (a) PAWS protection is necessary for the connection. > (b) An RTT measurement using timestamps is desired, and one such measurement > is in progress. We consider a measurement to be in progress if sender has > sent a timestamp after it started a measurement and it is not yet echoed > back. > (c) Retransmission of a segment upon timeout. > > Receiver-TCP would put a timestamp (or echo what it got) in an ack if: > (a) no more than 3 acks have been sent after any segment with a timestamp > was received. > > An Eifel-TCP-Sender would consider an acknowledgement received after a > timeout to be for the original segment if (a) the acknowledgemet does not > contain a timestamp or (b) the echoed timestamp is less than the timestamp > sent in the retransmitted segment. > > Thanks, > Sanjay > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Sun Jan 6 08:13:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23185 for ; Sun, 6 Jan 2002 08:13:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21834 for tsvwg-archive@odin.ietf.org; Sun, 6 Jan 2002 08:13:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21302; Sun, 6 Jan 2002 07:57:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21274 for ; Sun, 6 Jan 2002 07:57:57 -0500 (EST) Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.130.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23109 for ; Sun, 6 Jan 2002 07:57:52 -0500 (EST) Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:2182 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Sun, 6 Jan 2002 14:57:50 +0200 Message-ID: <03a701c196b1$baa5f260$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "sanjay kaniyar" , Cc: "Reiner Ludwig" References: Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: Date: Sun, 6 Jan 2002 14:57:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Sanjay- Restarting the retransmit timer upon fast retransmit is a common implementation strategy among existing TCPs. However, it's not yet recommended in any RFC to my knowledge. It is indeed a useful feature to decrease probability of a spurious timeout during fast recovery. But the additional time it gives is really only time to receive 3 DUPACKs, which is usually much less than RTT. It happens because the retransmit timer is restarted upon an ACK just before DUPACKs start to arrive. In other words, the actual time when the retransmit timer fires is RTT+RTO counting from the moment when the segment for which DUPACK arrives had been originally transmitted. Andrei ----- Original Message ----- From: "sanjay kaniyar" To: Sent: Friday, December 28, 2001 1:41 AM Subject: [Tsvwg] TCP Question about Fast-retransmit: > Upon reception of a 3rd duplicate acknowledgement, sender TCP retransmits > what it thinks is the missing segment and goes ahead with the rest of the > alogorithm. > > In case where the RTO is closely tracking the true RTT of the connection, it > would invariably end up handling a retransmission timeout because - by the > time duplicate acks are received by the sender, approximately 1 RTT would > have expired and by the time any ack for the new data arrives, 1 more RTT > would have expired. > > So, why not restart the Retransmission timer when a fast-retransmit happens? > > Thanks, > Sanjay > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Sun Jan 6 16:09:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26251 for ; Sun, 6 Jan 2002 16:09:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02419 for tsvwg-archive@odin.ietf.org; Sun, 6 Jan 2002 16:09:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01796; Sun, 6 Jan 2002 15:50:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01768 for ; Sun, 6 Jan 2002 15:50:04 -0500 (EST) Received: from hotmail.com (f3.law3.hotmail.com [209.185.241.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26128 for ; Sun, 6 Jan 2002 15:49:58 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 6 Jan 2002 12:49:32 -0800 Received: from 207.46.137.9 by lw3fd.law3.hotmail.msn.com with HTTP; Sun, 06 Jan 2002 20:49:31 GMT X-Originating-IP: [207.46.137.9] From: "sanjay kaniyar" To: gurtov@cs.helsinki.fi, tsvwg@ietf.org Cc: reiner.ludwig@ericsson.com Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: Date: Sun, 06 Jan 2002 12:49:31 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2002 20:49:32.0182 (UTC) FILETIME=[A45C5B60:01C196F3] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Thanks Andrei. I don't understand why you say the time required to receive 3 dup-acks would be usually much less than the RTT though. In a case where any one of the last 3 segments of a window sent are lost, this time would be (slightly greater than) 1 RTT. I guess, this is what you meant when you said it would be '1 RTT + 1 RTO'? Sanjay >From: "Andrei Gurtov" >To: "sanjay kaniyar" , >CC: "Reiner Ludwig" >Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: >Date: Sun, 6 Jan 2002 14:57:42 +0200 > >Sanjay- > >Restarting the retransmit timer upon fast retransmit is a common >implementation strategy among existing TCPs. However, it's not yet >recommended in any RFC to my knowledge. > >It is indeed a useful feature to decrease probability of a spurious timeout >during fast recovery. But the additional time it gives is really only time >to receive 3 DUPACKs, which is usually much less than RTT. It happens >because the retransmit timer is restarted upon an ACK just before DUPACKs >start to arrive. In other words, the actual time when the retransmit timer >fires is RTT+RTO counting from the moment when the segment for which DUPACK >arrives had been originally transmitted. > >Andrei > >----- Original Message ----- >From: "sanjay kaniyar" >To: >Sent: Friday, December 28, 2001 1:41 AM >Subject: [Tsvwg] TCP Question about Fast-retransmit: > > > > Upon reception of a 3rd duplicate acknowledgement, sender TCP >retransmits > > what it thinks is the missing segment and goes ahead with the rest of >the > > alogorithm. > > > > In case where the RTO is closely tracking the true RTT of the >connection, >it > > would invariably end up handling a retransmission timeout because - by >the > > time duplicate acks are received by the sender, approximately 1 RTT >would > > have expired and by the time any ack for the new data arrives, 1 more >RTT > > would have expired. > > > > So, why not restart the Retransmission timer when a fast-retransmit >happens? > > > > Thanks, > > Sanjay > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/tsvwg > > > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Sun Jan 6 16:56:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26692 for ; Sun, 6 Jan 2002 16:56:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03249 for tsvwg-archive@odin.ietf.org; Sun, 6 Jan 2002 16:56:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03132; Sun, 6 Jan 2002 16:35:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03103 for ; Sun, 6 Jan 2002 16:35:37 -0500 (EST) Received: from hotmail.com (f78.law3.hotmail.com [209.185.241.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26475 for ; Sun, 6 Jan 2002 16:35:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 6 Jan 2002 13:35:05 -0800 Received: from 207.46.137.8 by lw3fd.law3.hotmail.msn.com with HTTP; Sun, 06 Jan 2002 21:35:04 GMT X-Originating-IP: [207.46.137.8] From: "sanjay kaniyar" To: gurtov@cs.helsinki.fi, tsvwg@ietf.org Cc: Reiner.Ludwig@ericsson.com Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Date: Sun, 06 Jan 2002 13:35:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2002 21:35:05.0055 (UTC) FILETIME=[0147AEF0:01C196FA] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Thanks Andrei. 1. I would be suprised if there are TCPs/PEPs which can't handle repacketization. They should probably be fixed (PMTU discovery/change, SACK etc. comes to mind). 2. Can you elaborate why you think this scheme would be less robust? 3. The overhead would be small in (full sized) data segments but not in acknowledgements. 4. If the sender-TCP considers timing every segment useful, it should go ahead and do so. My argument is that, there should be allowance (and specification) for using timestamps only when it is necessary/useful to do so (just like SACK). The Eifel draft seems to me like a good place to address this (as well as the suggestion about restarting the retransmit timer after fast-retransmit)? Sanjay >From: "Andrei Gurtov" >To: "sanjay kaniyar" , >CC: >Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. >Date: Sun, 6 Jan 2002 13:57:10 +0200 > >Sanjay- > >A number of conerns were raised with such approach. First, it leads to >frequent repacketization of data segment as follows. Original segments sent >without the timestamp option each carry MSS bytes of data. After RTO, >segments have the timestamp option which occupies 12 bytes leaving less >space for data. Consequently, the sequence of retransmitted segments will >be >different than of original segments. In principle, this type of behavior is >legal and used by BSD systems. However, there are probably some TCPs and >PEPs around that cannot handle it well. Thus, 'be conservative in what you >send' approach may apply here. >The other concern is that the detection may be less robust in presense of >lost segments and ACKs. > >The timestamp overhead is not that big for large MTU (0.8% for 1500 B) and >ROHC is expected to compress TCP options. Additionally, there is some >evidence that timing every segment with timestamps is good on >bandwidth-limited paths. Based on these considerations, the current >understanding is to include timestamps in every segment. > >Andrei > >----- Original Message ----- >From: "sanjay kaniyar" >To: >Cc: >Sent: Tuesday, January 01, 2002 12:53 AM >Subject: [Tsvwg] Eifel draft and usage of time-stamps. > > > > I have seen the spurious retransmission problem occur in my experiments >with > > GPRS networks. The frequency of occurrence seems to be quite small >though, > > about once or twice during the transmission of a 500 K Bytes file with >an > > MSS of 1500 bytes. Ofcourse, I agree that this frequency could vary with > > different networks. In this case, however, incurring 12 bytes of >overhead >in > > every segment and acknowledgemnt seems quite a bit. > > > > Since it is not necessary to timestamp every segment and acknowledgement > > when timestamp option is enabled on a connection, we could do it only >when > > it is necessary. It is the sender which determines when this is >necessary, > > and the following approach is backwards compatible in the sense that a > > sender taking this approach would work properly with a receiver adhering >to > > the traditional time-stamping approach and vice-versa. > > > > Sender-TCP would put a timestamp in a segment if: > > (a) PAWS protection is necessary for the connection. > > (b) An RTT measurement using timestamps is desired, and one such >measurement > > is in progress. We consider a measurement to be in progress if sender >has > > sent a timestamp after it started a measurement and it is not yet echoed > > back. > > (c) Retransmission of a segment upon timeout. > > > > Receiver-TCP would put a timestamp (or echo what it got) in an ack if: > > (a) no more than 3 acks have been sent after any segment with a >timestamp > > was received. > > > > An Eifel-TCP-Sender would consider an acknowledgement received after a > > timeout to be for the original segment if (a) the acknowledgemet does >not > > contain a timestamp or (b) the echoed timestamp is less than the >timestamp > > sent in the retransmitted segment. > > > > Thanks, > > Sanjay > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/tsvwg > > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >http://www1.ietf.org/mailman/listinfo/tsvwg _________________________________________________________________ Join the world뭩 largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Mon Jan 7 15:17:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26824 for ; Mon, 7 Jan 2002 15:17:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20037 for tsvwg-archive@odin.ietf.org; Mon, 7 Jan 2002 15:17:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19214; Mon, 7 Jan 2002 14:56:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19181 for ; Mon, 7 Jan 2002 14:56:45 -0500 (EST) Received: from tweets.austin.ibm.com (pixpat.austin.ibm.com [192.35.232.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26244 for ; Mon, 7 Jan 2002 14:56:42 -0500 (EST) Received: from austin.ibm.com (localhost.austin.ibm.com [127.0.0.1] (may be forged)) by tweets.austin.ibm.com (AIX5.1/8.11.0/8.11.0) with ESMTP id g07JuDQ29876 for ; Mon, 7 Jan 2002 13:56:13 -0600 Message-ID: <3C39FD5D.739D2705@austin.ibm.com> Date: Mon, 07 Jan 2002 13:56:13 -0600 From: Kavitha Baratakke Reply-To: kavithab@austin.ibm.com Organization: IBM corporation X-Mailer: Mozilla 4.76iC-CCK-MCD [en_US] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP Heartbeat related questions Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit I have a couple of questions related to heartbeat api: 1) When a destination transport address has been marked inactive the RFC says that a NETWORK STATUS CHANGE notification may be invoked on the ULP. (10.2 SCTP-to-ULP sub-section C)). However the Socket API draft does not discuss anything about this notification. Was this missed? or is this to be an implementor's choice? 2) Nothing has been discussed in the Socket API extentions draft, about disabling/enabling heartbeats for specific destination transport address from an user-level application. I would appreciate a response. FYI, in the Socket API draft the SCTP_NODELAY option has been specified as the SO_NODELAY options in the index (page 1 of the draft). Also, in the index the SCTP_SEND_FAILED Notification is mispelt as SCTP_SEND_FAILE Thanks, Kavitha _________________________________________________________ Kavitha V. Baratakke IBM AIX TCP/IP Development Group 11501, Burnet Road, Bldg.905,5D-018, Austin, TX - 78758 _________________________________________________________ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Mon Jan 7 15:40:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27500 for ; Mon, 7 Jan 2002 15:40:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20883 for tsvwg-archive@odin.ietf.org; Mon, 7 Jan 2002 15:40:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20309; Mon, 7 Jan 2002 15:24:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20280 for ; Mon, 7 Jan 2002 15:24:29 -0500 (EST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27001 for ; Mon, 7 Jan 2002 15:24:26 -0500 (EST) Received: from ieee.org ([12.248.77.94]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020107202358.SKAS24940.rwcrmhc53.attbi.com@ieee.org>; Mon, 7 Jan 2002 20:23:58 +0000 Message-ID: <3C3A03C2.9095DECF@ieee.org> Date: Mon, 07 Jan 2002 14:23:30 -0600 From: Peter Lei X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kavithab@austin.ibm.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Heartbeat related questions References: <3C39FD5D.739D2705@austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Kavitha, Kavitha Baratakke wrote: > > I have a couple of questions related to heartbeat api: > > 1) When a destination transport address has been marked inactive the RFC > says that a NETWORK STATUS CHANGE notification may be invoked on the > ULP. (10.2 SCTP-to-ULP sub-section C)). However the Socket API draft > does not discuss anything about this notification. Was this missed? or > is this to be an implementor's choice? This is addressed by SCTP_PEER_ADDR_CHANGE: ADDRESS_UNREACHABLE notification event in the draft. > 2) Nothing has been discussed in the Socket API extentions draft, about > disabling/enabling heartbeats for specific destination transport address > from an user-level application. This is addressed by the SCTP_SET_PEER_ADDR_PARAMS socket option-- setting the heartbeat interval to 0 indicates that heartbeating should be disabled for that peer dest address. A non-zero value indicates the HB interval in msec (except the special case of MAX_UINT32). --peter > I would appreciate a response. > > FYI, in the Socket API draft the SCTP_NODELAY option has been specified > as the SO_NODELAY options in the index (page 1 of the draft). Also, in > the index the SCTP_SEND_FAILED Notification is mispelt as > SCTP_SEND_FAILE > > Thanks, > Kavitha > _________________________________________________________ > > Kavitha V. Baratakke > IBM AIX TCP/IP Development Group > 11501, Burnet Road, Bldg.905,5D-018, Austin, TX - 78758 > _________________________________________________________ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Tue Jan 8 08:07:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20046 for ; Tue, 8 Jan 2002 08:07:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27951 for tsvwg-archive@odin.ietf.org; Tue, 8 Jan 2002 08:07:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27134; Tue, 8 Jan 2002 07:42:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27103 for ; Tue, 8 Jan 2002 07:42:38 -0500 (EST) Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.130.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19862 for ; Tue, 8 Jan 2002 07:42:36 -0500 (EST) Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:1322 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Tue, 8 Jan 2002 14:42:18 +0200 Message-ID: <002301c19841$e7616320$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "sanjay kaniyar" , Cc: References: Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: Date: Tue, 8 Jan 2002 14:42:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Sanjay, You right when the window and network delay is relatively small, then receiving 3 DUPACKs takes time close to one RTT. Figure2 of the tech report shows fast retransmit with and without restart of the retransmit timer http://www.cs.helsinki.fi/u/gurtov/papers/report01.html Section 3.3 of the Eifel timer paper explains the issue of REXMT=RTO+RTT http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Xmit/index.html Andrei ----- Original Message ----- From: "sanjay kaniyar" To: ; Cc: Sent: Sunday, January 06, 2002 10:49 PM Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: > Thanks Andrei. > > I don't understand why you say the time required to receive 3 dup-acks would > be usually much less than the RTT though. In a case where any one of the > last 3 segments of a window sent are lost, this time would be (slightly > greater than) 1 RTT. I guess, this is what you meant when you said it would > be '1 RTT + 1 RTO'? > > Sanjay > > >From: "Andrei Gurtov" > >To: "sanjay kaniyar" , > >CC: "Reiner Ludwig" > >Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: > >Date: Sun, 6 Jan 2002 14:57:42 +0200 > > > >Sanjay- > > > >Restarting the retransmit timer upon fast retransmit is a common > >implementation strategy among existing TCPs. However, it's not yet > >recommended in any RFC to my knowledge. > > > >It is indeed a useful feature to decrease probability of a spurious timeout > >during fast recovery. But the additional time it gives is really only time > >to receive 3 DUPACKs, which is usually much less than RTT. It happens > >because the retransmit timer is restarted upon an ACK just before DUPACKs > >start to arrive. In other words, the actual time when the retransmit timer > >fires is RTT+RTO counting from the moment when the segment for which DUPACK > >arrives had been originally transmitted. > > > >Andrei > > > >----- Original Message ----- > >From: "sanjay kaniyar" > >To: > >Sent: Friday, December 28, 2001 1:41 AM > >Subject: [Tsvwg] TCP Question about Fast-retransmit: > > > > > > > Upon reception of a 3rd duplicate acknowledgement, sender TCP > >retransmits > > > what it thinks is the missing segment and goes ahead with the rest of > >the > > > alogorithm. > > > > > > In case where the RTO is closely tracking the true RTT of the > >connection, > >it > > > would invariably end up handling a retransmission timeout because - by > >the > > > time duplicate acks are received by the sender, approximately 1 RTT > >would > > > have expired and by the time any ack for the new data arrives, 1 more > >RTT > > > would have expired. > > > > > > So, why not restart the Retransmission timer when a fast-retransmit > >happens? > > > > > > Thanks, > > > Sanjay > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > tsvwg mailing list > > > tsvwg@ietf.org > > > http://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Tue Jan 8 09:25:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22895 for ; Tue, 8 Jan 2002 09:25:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01127 for tsvwg-archive@odin.ietf.org; Tue, 8 Jan 2002 09:25:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00201; Tue, 8 Jan 2002 09:02:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00168 for ; Tue, 8 Jan 2002 09:02:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21784; Tue, 8 Jan 2002 09:02:02 -0500 (EST) Message-Id: <200201081402.JAA21784@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Jan 2002 09:02:02 -0500 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-01.txt Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org --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 : SCTP Checksum Change Author(s) : R. Stewart, C. Sharp, J. Stone, D. Otis Filename : draft-ietf-tsvwg-sctpcsum-01.txt Pages : 10 Date : 07-Jan-02 SCTP [RFC2960] currently uses an Adler-32 checksum. For small packets, this provides weak protection against the detection of errors. This document changes that checksum and updates SCTP to use a 32 bit CRC checksum. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpcsum-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sctpcsum-01.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-sctpcsum-01.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: <20020107135620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpcsum-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpcsum-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107135620.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Tue Jan 8 22:19:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17994 for ; Tue, 8 Jan 2002 22:19:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA04434 for tsvwg-archive@odin.ietf.org; Tue, 8 Jan 2002 22:19:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04156; Tue, 8 Jan 2002 22:04:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04128 for ; Tue, 8 Jan 2002 22:04:34 -0500 (EST) Received: from viola.demizu.org (h034.p106.iij4u.or.jp [210.130.106.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17759 for ; Tue, 8 Jan 2002 22:04:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by viola.demizu.org (8.11.0/8.11.0) with ESMTP id g0932RL00337; Wed, 9 Jan 2002 12:02:29 +0900 (JST) From: Noritoshi Demizu To: gurtov@cs.helsinki.fi Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: In-Reply-To: Your message of "Tue, 8 Jan 2002 14:42:15 +0200" References: <002301c19841$e7616320$6b24b183@etela.sonera.fi> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020109120226I.demizu@dd.iij4u.or.jp> Date: Wed, 09 Jan 2002 12:02:26 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 29 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Andrei, > You right when the window and network delay is relatively small, then > receiving 3 DUPACKs takes time close to one RTT. When you use Limited Transmit [RFC3042], it may take 3 RTTs in the worst case. Example scenario: 1. sent data(1). got ack(2). cwnd becomes 2MSS. 2. sent data(2) & data(3). start rxmt timer. but data(2) lost. 3. got ack(2) again. dupacks=1. (1RTT later from 2.) 4. sent data(4) because of limited transmit. 5. got ack(2) again. dupacks=2. (2RTT later from 2.) 6. sent data(5) because of limited transmit. 7. got ack(2) again. dupacks=3. (3RTT later from 2.) 8. sent data(2) because of fast retransmit. 9. got ack(6). In the case where 3 RTT < RTO < 4 RTT, if retransmission timer is not restarted by step 8, data(2) will be sent again without waiting for the ACK for the packet sent by step 8. Thinking of other scenarios with limited transmit, if retransmission timer is not restarted on fast retransmit, spurious retransmit could occure if RTO < 4 RTT. (RTO < 2RTT for cases without limited transmit) Regards, Noritoshi Demizu _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Tue Jan 8 22:35:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19054 for ; Tue, 8 Jan 2002 22:35:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA04984 for tsvwg-archive@odin.ietf.org; Tue, 8 Jan 2002 22:35:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04479; Tue, 8 Jan 2002 22:22:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04451 for ; Tue, 8 Jan 2002 22:22:32 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18036 for ; Tue, 8 Jan 2002 22:22:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA03730; Tue, 8 Jan 2002 19:22:30 -0800 (PST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA16974; Tue, 8 Jan 2002 19:22:30 -0800 (PST) Date: Tue, 8 Jan 2002 19:21:51 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Section 4.1.9 sctpsocket-02.txt To: "Kimble Scott (NET/MtView)" Cc: tsvwg@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Sorry for the late reply. I was on vacation the last month... > Section 4.1.9 sctpsocket-02.txt > > getsockname() is applicable to both TCP-Style and UDP-Style SCTP > instances. Section 4.1.9 can be moved to section 6. Can you explain why? For UDP-style socket, an fd is associated with many associations. And the different associations may actually have different local info. If getsockname() is applied to a UDP-style socket, which associations' local info should be returned? K. Poon. kcpoon@eng.sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Tue Jan 8 23:07:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19512 for ; Tue, 8 Jan 2002 23:07:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA05884 for tsvwg-archive@odin.ietf.org; Tue, 8 Jan 2002 23:07:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05136; Tue, 8 Jan 2002 22:45:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05108 for ; Tue, 8 Jan 2002 22:45:45 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19328 for ; Tue, 8 Jan 2002 22:45:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21018; Tue, 8 Jan 2002 20:45:27 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA19556; Tue, 8 Jan 2002 19:45:45 -0800 (PST) Date: Tue, 8 Jan 2002 19:45:05 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Question on socket options To: kavithab@austin.ibm.com Cc: tsvwg@ietf.org In-Reply-To: "Your message with ID" <3C2CA942.61097251@austin.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > In the section 7 of the "Sockets API Extensions for SCTP" draft where > various SCTP level socket options > are defined, options SO_LINGER, SO_NODELAY, SO_RCVBUF, SO_SNDBUF are > also mentioned? Shouldn't these be socket-level options (SOL_SOCKET) > and not SCTP level? Strictly speaking, they are transport level options. But unfortunately, the BSD socket API has them defined in the socket level. Since we want to allow current TCP apps to be ported to use SCTP without changes (except for using a new protocol in the socket() call) if possible, we have to follow the current socket API practise. > Also, there is a typo on page 47, probably just a "cut n paste" > overlook! > > /* if a send fails we want to know it */ > if (setsockopt(fd, IPPROTO_SCTP, SCTP_RECVSENDFAILEVNT, > &onoff, 4) < 0) { > perror("setsockopt SCTP_RECVASSOCEVNT"); > exit(1); Thanks. K. Poon. kcpoon@eng.sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 00:02:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20404 for ; Wed, 9 Jan 2002 00:02:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA07334 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 00:02:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06737; Tue, 8 Jan 2002 23:43:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06708 for ; Tue, 8 Jan 2002 23:43:53 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20207 for ; Tue, 8 Jan 2002 23:43:51 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g094hpA03624; Tue, 8 Jan 2002 23:43:51 -0500 Message-Id: <200201090443.g094hpA03624@minotaur.nge.isi.edu> To: tsvwg@ietf.org, rrs@cisco.co, chsharp@cisco.com, jonathan@dsg.stanford.edu, dotis@sanlight.net Reply-To: mankin@isi.edu Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Jan 2002 23:43:51 -0500 From: Allison Mankin Subject: [Tsvwg] Working Group Last Call on SCTP checksum change Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Authors and Transport Working Group: This is the working group last call on the SCTP checksum change draft, draft-ietf-tsvwg-sctpsum-01.txt, which has been anounced today. Please make comments to the working group list preferably (and editorial comments to the authors) by Tuesday, January 22. The ADs have two changes to request: 1. The draft needs to have a Security Considerations section, which we know the authors already noticed. We'd like the text for this to be sent to the WG list so it can be WGLC'd too.. 2. The draft should have an IANA Considerations section that states that there is no work for the IANA in it :) Thanks, Allison and Scott _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 08:12:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03410 for ; Wed, 9 Jan 2002 08:12:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00837 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 08:12:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29967; Wed, 9 Jan 2002 07:53:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29936 for ; Wed, 9 Jan 2002 07:53:19 -0500 (EST) Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.130.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03203 for ; Wed, 9 Jan 2002 07:53:16 -0500 (EST) Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:1804 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Wed, 9 Jan 2002 14:52:58 +0200 Message-ID: <009701c1990c$8d6be400$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "sanjay kaniyar" , Cc: References: Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Date: Wed, 9 Jan 2002 14:52:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Sanjay, Thanks for your points. As you see, I don't have a strong opinion about this issue. > 1. I would be suprised if there are TCPs/PEPs which can't handle > repacketization. They should probably be fixed (PMTU discovery/change, SACK > etc. comes to mind). Right, but repacketization due to PMTU and SACK seems to be a rare event... > 2. Can you elaborate why you think this scheme would be less robust? Well, if a timestamp is put only in retransmitted segments, then lack of timestamp is an indication of a spurious timeout. What if the receiver implements some own bandwidth-saving policy and echos every 3rd timestamps or so? Arguably, deliberately lying with a timestamp value is less likely. > 3. The overhead would be small in (full sized) data segments but not in > acknowledgements. Good point, but ACK are themself small, sent for every-second data segment and are ROHC compressable. > 4. If the sender-TCP considers timing every segment useful, it should go > ahead and do so. Without timestamps it is more complex to implement... Andrei > > My argument is that, there should be allowance (and specification) for using > timestamps only when it is necessary/useful to do so (just like SACK). The > Eifel draft seems to me like a good place to address this (as well as the > suggestion about restarting the retransmit timer after fast-retransmit)? > > Sanjay > > > >From: "Andrei Gurtov" > >To: "sanjay kaniyar" , > >CC: > >Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. > >Date: Sun, 6 Jan 2002 13:57:10 +0200 > > > >Sanjay- > > > >A number of conerns were raised with such approach. First, it leads to > >frequent repacketization of data segment as follows. Original segments sent > >without the timestamp option each carry MSS bytes of data. After RTO, > >segments have the timestamp option which occupies 12 bytes leaving less > >space for data. Consequently, the sequence of retransmitted segments will > >be > >different than of original segments. In principle, this type of behavior is > >legal and used by BSD systems. However, there are probably some TCPs and > >PEPs around that cannot handle it well. Thus, 'be conservative in what you > >send' approach may apply here. > >The other concern is that the detection may be less robust in presense of > >lost segments and ACKs. > > > >The timestamp overhead is not that big for large MTU (0.8% for 1500 B) and > >ROHC is expected to compress TCP options. Additionally, there is some > >evidence that timing every segment with timestamps is good on > >bandwidth-limited paths. Based on these considerations, the current > >understanding is to include timestamps in every segment. > > > >Andrei > > > >----- Original Message ----- > >From: "sanjay kaniyar" > >To: > >Cc: > >Sent: Tuesday, January 01, 2002 12:53 AM > >Subject: [Tsvwg] Eifel draft and usage of time-stamps. > > > > > > > I have seen the spurious retransmission problem occur in my experiments > >with > > > GPRS networks. The frequency of occurrence seems to be quite small > >though, > > > about once or twice during the transmission of a 500 K Bytes file with > >an > > > MSS of 1500 bytes. Ofcourse, I agree that this frequency could vary with > > > different networks. In this case, however, incurring 12 bytes of > >overhead > >in > > > every segment and acknowledgemnt seems quite a bit. > > > > > > Since it is not necessary to timestamp every segment and acknowledgement > > > when timestamp option is enabled on a connection, we could do it only > >when > > > it is necessary. It is the sender which determines when this is > >necessary, > > > and the following approach is backwards compatible in the sense that a > > > sender taking this approach would work properly with a receiver adhering > >to > > > the traditional time-stamping approach and vice-versa. > > > > > > Sender-TCP would put a timestamp in a segment if: > > > (a) PAWS protection is necessary for the connection. > > > (b) An RTT measurement using timestamps is desired, and one such > >measurement > > > is in progress. We consider a measurement to be in progress if sender > >has > > > sent a timestamp after it started a measurement and it is not yet echoed > > > back. > > > (c) Retransmission of a segment upon timeout. > > > > > > Receiver-TCP would put a timestamp (or echo what it got) in an ack if: > > > (a) no more than 3 acks have been sent after any segment with a > >timestamp > > > was received. > > > > > > An Eifel-TCP-Sender would consider an acknowledgement received after a > > > timeout to be for the original segment if (a) the acknowledgemet does > >not > > > contain a timestamp or (b) the echoed timestamp is less than the > >timestamp > > > sent in the retransmitted segment. > > > > > > Thanks, > > > Sanjay > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > > > > _______________________________________________ > > > tsvwg mailing list > > > tsvwg@ietf.org > > > http://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > > >_______________________________________________ > >tsvwg mailing list > >tsvwg@ietf.org > >http://www1.ietf.org/mailman/listinfo/tsvwg > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 08:23:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03510 for ; Wed, 9 Jan 2002 08:23:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01028 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 08:23:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00757; Wed, 9 Jan 2002 08:08:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00716 for ; Wed, 9 Jan 2002 08:08:29 -0500 (EST) Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.130.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03376 for ; Wed, 9 Jan 2002 08:08:26 -0500 (EST) Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:1817 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Wed, 9 Jan 2002 15:08:18 +0200 Message-ID: <00ab01c1990e$b14ba0c0$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "Noritoshi Demizu" Cc: References: <002301c19841$e7616320$6b24b183@etela.sonera.fi> <20020109120226I.demizu@dd.iij4u.or.jp> Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: Date: Wed, 9 Jan 2002 15:08:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Noritoshi, Thanks for a very interesting example! I also observed that LT makes a spurious timeout more likely during fast recovery due to a longer DUPACK series. Andrei ----- Original Message ----- From: "Noritoshi Demizu" To: Cc: Sent: Wednesday, January 09, 2002 5:02 AM Subject: Re: [Tsvwg] TCP Question about Fast-retransmit: > Andrei, > > > You right when the window and network delay is relatively small, then > > receiving 3 DUPACKs takes time close to one RTT. > > When you use Limited Transmit [RFC3042], it may take 3 RTTs in the > worst case. > > Example scenario: > 1. sent data(1). got ack(2). cwnd becomes 2MSS. > 2. sent data(2) & data(3). start rxmt timer. but data(2) lost. > 3. got ack(2) again. dupacks=1. (1RTT later from 2.) > 4. sent data(4) because of limited transmit. > 5. got ack(2) again. dupacks=2. (2RTT later from 2.) > 6. sent data(5) because of limited transmit. > 7. got ack(2) again. dupacks=3. (3RTT later from 2.) > 8. sent data(2) because of fast retransmit. > 9. got ack(6). > > In the case where 3 RTT < RTO < 4 RTT, if retransmission timer is not > restarted by step 8, data(2) will be sent again without waiting for > the ACK for the packet sent by step 8. > > Thinking of other scenarios with limited transmit, if retransmission > timer is not restarted on fast retransmit, spurious retransmit could > occure if RTO < 4 RTT. (RTO < 2RTT for cases without limited transmit) > > Regards, > Noritoshi Demizu > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 13:18:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08817 for ; Wed, 9 Jan 2002 13:18:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14210 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 13:18:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13222; Wed, 9 Jan 2002 12:51:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13191 for ; Wed, 9 Jan 2002 12:51:10 -0500 (EST) Received: from c003.snv.cp.net (c003-h013.c003.snv.cp.net [209.228.32.227]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08198 for ; Wed, 9 Jan 2002 12:51:08 -0500 (EST) Received: (cpmta 1177 invoked from network); 9 Jan 2002 09:50:39 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.227) with SMTP; 9 Jan 2002 09:50:39 -0800 X-Sent: 9 Jan 2002 17:50:39 GMT From: "Douglas Otis" To: "Tsvwg" Date: Wed, 9 Jan 2002 09:50:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Tsvwg] RE: Working Group Last Call on SCTP checksum change Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit This could be used to update the draft to satisfy the missing sections: 3 Security Considerations There may be a computational advantage in validating the Association against the Verification Tag prior to performing a checksum as invalid tags will result in the same action as a bad checksum in most cases. The exceptions for this technique would be INIT and some SHUTDOWN-COMPLETE exchanges as well as a stale COOKIE-ECHO. These special case exchanges must represent small packets and will minimize the effect of the checksum calculation. 4 IANA Considerations There are no IANA considerations required in this document. Doug _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 14:29:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13273 for ; Wed, 9 Jan 2002 14:29:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16819 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 14:29:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16486; Wed, 9 Jan 2002 14:10:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16457 for ; Wed, 9 Jan 2002 14:10:03 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12531 for ; Wed, 9 Jan 2002 14:10:00 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g09JABQ16293 for ; Wed, 9 Jan 2002 13:10:11 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 9 Jan 2002 13:10:01 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 9 Jan 2002 13:10:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-01.txt Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 9 Jan 2002 11:10:00 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0F8139@mvebe001.NOE.Nokia.com> Thread-Topic: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-01.txt Thread-Index: AcGYTSi12dYqpAQ+Edar0gAIx6S5QwAT9TbA From: "Sud Shivani (NET/MtView)" To: Cc: X-OriginalArrivalTime: 09 Jan 2002 19:10:01.0089 (UTC) FILETIME=[3C8D1F10:01C19941] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA16458 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 8bit Ref Pg 8 which has an example of the crc validation : /* Example of crc validation */ /* Test of 32 zeros should yield 0x756EC955 placed in network order */ /* 13 zeros followed by byte values of 1 - 0x1f should yield /* 0x5b988D47 */ Do you a mean an arbitrary buffer of 32 bytes - all zero ? Or an sctp (with a data chunk) packet with a payload of 32 bytes set to zero. I dont see how an all zero buffer can have a non-zero checksum. I am not getting either of the crc's using the example code. Shivani ! -----Original Message----- ! From: ext Internet-Drafts@ietf.org ! [mailto:Internet-Drafts@ietf.org] ! Sent: 08 January, 2002 6:02 AM ! Cc: tsvwg@ietf.org ! Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-01.txt ! ! ! 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 : SCTP Checksum Change ! Author(s) : R. Stewart, C. Sharp, J. Stone, D. Otis ! Filename : draft-ietf-tsvwg-sctpcsum-01.txt ! Pages : 10 ! Date : 07-Jan-02 ! ! SCTP [RFC2960] currently uses an Adler-32 checksum. For ! small packets, ! this provides weak protection against the detection of ! errors. This ! document changes that checksum and updates SCTP to use a ! 32 bit CRC ! checksum. ! ! A URL for this Internet-Draft is: ! http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpcs um-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sctpcsum-01.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-sctpcsum-01.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. _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 16:15:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15882 for ; Wed, 9 Jan 2002 16:15:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20254 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 16:15:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19807; Wed, 9 Jan 2002 16:00:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19759 for ; Wed, 9 Jan 2002 16:00:42 -0500 (EST) Received: from c003.snv.cp.net (c003-h016.c003.snv.cp.net [209.228.32.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15143 for ; Wed, 9 Jan 2002 16:00:37 -0500 (EST) Received: (cpmta 18681 invoked from network); 9 Jan 2002 13:00:08 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.230) with SMTP; 9 Jan 2002 13:00:08 -0800 X-Sent: 9 Jan 2002 21:00:08 GMT From: "Douglas Otis" To: "Tsvwg" Subject: RE: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-01.txt Date: Wed, 9 Jan 2002 13:00:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Shivani, The test was an arbitrary buffer. The second test case was to allow an architecture check on the data path. The initialization of the CRC register provides for a non-zero result even with an all zeros buffer. Doug > Ref Pg 8 which has an example of the crc validation : > > /* Example of crc validation */ > /* Test of 32 zeros should yield 0x756EC955 placed in network order > */ > /* 13 zeros followed by byte values of 1 - 0x1f should yield > /* 0x5b988D47 */ > > Do you a mean an arbitrary buffer of 32 bytes - all zero ? Or an sctp > (with a data chunk) packet with a payload of 32 bytes set to zero. > I dont see how an all zero buffer can have a non-zero checksum. > I am not getting either of the crc's using the example code. > > Shivani > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 17:52:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19208 for ; Wed, 9 Jan 2002 17:52:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22980 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 17:52:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22826; Wed, 9 Jan 2002 17:37:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22794 for ; Wed, 9 Jan 2002 17:37:29 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18434 for ; Wed, 9 Jan 2002 17:37:26 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02060; Wed, 9 Jan 2002 15:37:09 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA28520; Wed, 9 Jan 2002 14:37:27 -0800 (PST) Date: Wed, 9 Jan 2002 14:36:43 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. To: sanjay kaniyar Cc: tsvwg@ietf.org, Reiner.Ludwig@Ericsson.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > Since it is not necessary to timestamp every segment and acknowledgement > when timestamp option is enabled on a connection, we could do it only when > it is necessary. It is the sender which determines when this is necessary, > and the following approach is backwards compatible in the sense that a > sender taking this approach would work properly with a receiver adhering to > the traditional time-stamping approach and vice-versa. I may have missed some of the discussions in this thread.... But I believe it is specified in RFC 1323 that if timestamp option is used, it has to be in every TCP segments sent. As a matter of fact, in Solaris, if one side suddenly stops sending timestamp option, the Solaris side will also stop sending it and will ignore future timestamp option as it thinks that the other must have some problems and the timestamp option may not provide correct info. So I'm afraid your suggestion may not be backward compatibile with RFC 1323. K. Poon. kcpoon@eng.sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 20:11:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23012 for ; Wed, 9 Jan 2002 20:11:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27023 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 20:11:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26371; Wed, 9 Jan 2002 19:53:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26342 for ; Wed, 9 Jan 2002 19:53:22 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22629 for ; Wed, 9 Jan 2002 19:53:19 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id RAA18679; Wed, 9 Jan 2002 17:43:15 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA09627; Wed, 9 Jan 2002 17:53:20 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay2.cig.mot.com (8.11.4/8.11.4) with ESMTP id g0A0rH718332; Wed, 9 Jan 2002 18:53:17 -0600 (CST) Received: from cig.mot.com (d50-38e1.cig.mot.com [160.47.56.225]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA18957; Wed, 9 Jan 2002 18:57:58 -0600 (CST) Message-ID: <3C3CE66F.411905C8@cig.mot.com> Date: Wed, 09 Jan 2002 18:55:11 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Douglas Otis CC: Tsvwg Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit An important normative reference is missing in the checksum draft - [RFC2960] :-) -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 20:36:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23682 for ; Wed, 9 Jan 2002 20:36:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27659 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 20:36:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27166; Wed, 9 Jan 2002 20:24:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27137 for ; Wed, 9 Jan 2002 20:24:09 -0500 (EST) Received: from c003.snv.cp.net (c003-h015.c003.snv.cp.net [209.228.32.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23371 for ; Wed, 9 Jan 2002 20:24:06 -0500 (EST) Received: (cpmta 13635 invoked from network); 9 Jan 2002 17:23:37 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.229) with SMTP; 9 Jan 2002 17:23:37 -0800 X-Sent: 10 Jan 2002 01:23:37 GMT From: "Douglas Otis" To: "Qiaobing Xie" Cc: "Tsvwg" Subject: RE: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-01.txt Date: Wed, 9 Jan 2002 17:23:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3C3CE66F.411905C8@cig.mot.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Qiaobing, In the Reference Section add: [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, "Stream Control Transmission Protocol," RFC 2960, October 2000. Doug > An important normative reference is missing in the checksum draft - > [RFC2960] :-) > > -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 21:24:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24996 for ; Wed, 9 Jan 2002 21:24:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28830 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 21:24:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27968; Wed, 9 Jan 2002 20:56:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27938 for ; Wed, 9 Jan 2002 20:56:39 -0500 (EST) Received: from hotmail.com (f143.law3.hotmail.com [209.185.241.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24199 for ; Wed, 9 Jan 2002 20:56:35 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Jan 2002 17:56:08 -0800 Received: from 207.46.137.9 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 10 Jan 2002 01:56:07 GMT X-Originating-IP: [207.46.137.9] From: "sanjay kaniyar" To: kcpoon@eng.sun.com Cc: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Date: Wed, 09 Jan 2002 17:56:07 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jan 2002 01:56:08.0221 (UTC) FILETIME=[F87E64D0:01C19979] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org I browsed through 1323 but could not find it speicify that timestamps should be sent in every segment, once negotiated. However, I did find the following: "For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions." Is this what you were referring to? Not sure it implies what you said. Sanjay >From: Kacheong Poon >Reply-To: Kacheong Poon >To: sanjay kaniyar >CC: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com >Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. >Date: Wed, 9 Jan 2002 14:36:43 -0800 (PST) > > > Since it is not necessary to timestamp every segment and acknowledgement > > when timestamp option is enabled on a connection, we could do it only >when > > it is necessary. It is the sender which determines when this is >necessary, > > and the following approach is backwards compatible in the sense that a > > sender taking this approach would work properly with a receiver adhering >to > > the traditional time-stamping approach and vice-versa. > >I may have missed some of the discussions in this thread.... But >I believe it is specified in RFC 1323 that if timestamp option is >used, it has to be in every TCP segments sent. As a matter of fact, >in Solaris, if one side suddenly stops sending timestamp option, >the Solaris side will also stop sending it and will ignore future >timestamp option as it thinks that the other must have some problems >and the timestamp option may not provide correct info. So I'm afraid >your suggestion may not be backward compatibile with RFC 1323. > > K. Poon. > kcpoon@eng.sun.com > > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >http://www1.ietf.org/mailman/listinfo/tsvwg _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 21:53:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26730 for ; Wed, 9 Jan 2002 21:53:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29679 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 21:54:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28867; Wed, 9 Jan 2002 21:25:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28842 for ; Wed, 9 Jan 2002 21:25:22 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25090 for ; Wed, 9 Jan 2002 21:25:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA18514; Wed, 9 Jan 2002 18:25:18 -0800 (PST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA05218; Wed, 9 Jan 2002 18:25:17 -0800 (PST) Date: Wed, 9 Jan 2002 18:24:37 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. To: sanjay kaniyar Cc: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > I browsed through 1323 but could not find it speicify that timestamps should > be sent in every segment, once negotiated. However, I did find the > following: > > "For simplicity and symmetry, we specify that timestamps always be sent and > echoed in both directions." > > Is this what you were referring to? Not sure it implies what you said. Yes. Well, I intrepret always to be for every segments... How do you interpret that? And I believe all TCP implementations I have encountered always send a timestamp option in every segments. As a matter of fact, I am not sure if the RTTM or PAWS as specified work correctly if timestamp option is not sent and echoed in every segments... K. Poon. kcpoon@eng.sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 22:02:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26875 for ; Wed, 9 Jan 2002 22:02:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA00123 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 22:02:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29608; Wed, 9 Jan 2002 21:47:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29580 for ; Wed, 9 Jan 2002 21:47:32 -0500 (EST) Received: from hotmail.com (f100.law3.hotmail.com [209.185.241.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26585 for ; Wed, 9 Jan 2002 21:47:28 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Jan 2002 18:47:00 -0800 Received: from 131.107.3.92 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 10 Jan 2002 02:47:00 GMT X-Originating-IP: [131.107.3.92] From: "sanjay kaniyar" To: kcpoon@eng.sun.com Cc: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Date: Wed, 09 Jan 2002 18:47:00 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jan 2002 02:47:00.0924 (UTC) FILETIME=[140BE7C0:01C19981] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org I interpret it as 'don't use timestmaps in a unidirectional way'. Besides, I don't know of a TCP which would reject segments it receives on a timestamp negotiated connection just because it does not have timestamps. From what you said, Solaris also accepts such segments. The rest of the interpretation seems to be Solaris specific. As I suggested earlier, if PAWS check is necessary (easy to figure out for the sender), every segment should be timestamped. For RTTM, timestamping and taking an RTT measurement on every segment is really an overkill in a lot of cases. In my opinion, the primary reason why TCP-clients do not negotiate a timestamp option today is the constant overhead in terms of bandwidth it causes. If this were to be on a need only basis (like SACK), it would probably be more widely negotiated and it would enable wide spread deployment of Eifel-capable TCPs (probably, every mobile node would negotiate timestamps!). Sanjay >From: Kacheong Poon >Reply-To: Kacheong Poon >To: sanjay kaniyar >CC: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com >Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. >Date: Wed, 9 Jan 2002 18:24:37 -0800 (PST) > > > I browsed through 1323 but could not find it speicify that timestamps >should > > be sent in every segment, once negotiated. However, I did find the > >following: > > > "For simplicity and symmetry, we specify that timestamps always be sent >and > > echoed in both directions." > > > > Is this what you were referring to? Not sure it implies what you said. > >Yes. Well, I intrepret always to be for every segments... How do you >interpret that? And I believe all TCP implementations I have encountered >always send a timestamp option in every segments. As a matter of fact, >I am not sure if the RTTM or PAWS as specified work correctly if timestamp >option is not sent and echoed in every segments... > > K. Poon. > kcpoon@eng.sun.com > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 22:29:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27360 for ; Wed, 9 Jan 2002 22:29:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA00618 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 22:29:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00299; Wed, 9 Jan 2002 22:13:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00267 for ; Wed, 9 Jan 2002 22:13:32 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27159 for ; Wed, 9 Jan 2002 22:13:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15009; Wed, 9 Jan 2002 20:13:11 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA14392; Wed, 9 Jan 2002 19:13:28 -0800 (PST) Date: Wed, 9 Jan 2002 19:12:49 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. To: sanjay kaniyar Cc: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > I interpret it as 'don't use timestmaps in a unidirectional way'. Hmmm, a TCP connection is always bidirectional. And the option has to be negotiated by both sides. What do you really mean by "unidirectional?" > Besides, I don't know of a TCP which would reject segments it receives on a > timestamp negotiated connection just because it does not have timestamps. > From what you said, Solaris also accepts such segments. The rest of the > interpretation seems to be Solaris specific. It seems that you misinterpreted my comment. My comment is about ignoring the timestamp option, not rejecting segments. This is a major difference. And the other comment is that I don't know of any implementation which does not send timestamp option in every segment (besides, for example, RST) once it is negotiated at the beginning. And for the sake of the RTTM and PAWS, I believe it is safe to assume that if one side suddenly stops sending timestamp option, there must be something wrong and RTTM and PAWS will not be reliable. > As I suggested earlier, if PAWS check is necessary (easy to figure out for > the sender), every segment should be timestamped. For RTTM, timestamping and > taking an RTT measurement on every segment is really an overkill in a lot of > cases. Hmmm, when you say it is easy to figure out whether PAWS is needed, can you explain further? Nowadays, I believe most computers have 100Mbps NIC (I believe soon all gadgets with network connection will be like that). RFC 1323 clearly states the problem here. So are you saying that all connections should use PAWS then? I believe you are not suggesting that. Maybe you can explain your easy method. And can you also explain how you can tell taking an RTT measurement on every segment is an overkill at the beginning of a connection? > In my opinion, the primary reason why TCP-clients do not negotiate a > timestamp option today is the constant overhead in terms of bandwidth it > causes. If this were to be on a need only basis (like SACK), it would > probably be more widely negotiated and it would enable wide spread > deployment of Eifel-capable TCPs (probably, every mobile node would > negotiate timestamps!). Well, assuming that timestamp option is really rarely used nowadays, I believe there can be many other reasons... Not all stacks support timestamp option (there are still many old stacks out there...). The option is not turned on be default. ... Honestly, given today's network and ROHC for slow links, the 12 bytes overhead is really nothing for most people... This is my own conjecture without support. If you can substantiate your own overhead conjecture, I'll buy it (-: K. Poon. kcpoon@eng.sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Wed Jan 9 23:15:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29139 for ; Wed, 9 Jan 2002 23:15:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA02046 for tsvwg-archive@odin.ietf.org; Wed, 9 Jan 2002 23:15:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01690; Wed, 9 Jan 2002 23:00:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01628 for ; Wed, 9 Jan 2002 23:00:26 -0500 (EST) Received: from hotmail.com (f127.law3.hotmail.com [209.185.241.127]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28865 for ; Wed, 9 Jan 2002 23:00:21 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Jan 2002 19:59:54 -0800 Received: from 207.46.137.8 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 10 Jan 2002 03:59:54 GMT X-Originating-IP: [207.46.137.8] From: "sanjay kaniyar" To: kcpoon@eng.sun.com Cc: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Date: Wed, 09 Jan 2002 19:59:54 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jan 2002 03:59:54.0758 (UTC) FILETIME=[430E0260:01C1998B] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org 1. Data transfer could be unidirectional, in which case timestamps would only be necessary for the direction of data flow. Somewhere in the 1323, they mention that they chose to 'always' use it bidirectionally for the purpose of simplicity etc. 2. I did not misinterpret your comment, I understood that Solaris does not reject segments without timestamps. My point is that, the behavior of 'considering the peer to be not able to generate timestamps accurately just because some segments did not have timestamps' is what is Solaris speicific. 3. It may not be necessary to time every segment in cases like, for example, where it does not change much at all? or maybe timing every 3rd segment is just as good? or maybe it is too small and the sender TCP is going to stick to its attainable minimum? 4. It is possible to say a connection does not need PAWS check based on the perceived RTT and the advertised receive window size, for example. Or if there is a limit set on the maximum bandwidth a connection can use etc. 5. Whether 12 bytes in each segment and ack is an overhead or not (with ROHC or without) is quite subjective, I think. To me, a single byte that goes on the wire that does not have any purpose to it is an overhead and should be avoided if it is not too much of an engineering overhead (and I believe with timestamps it is not). Sanjay. >From: Kacheong Poon >Reply-To: Kacheong Poon >To: sanjay kaniyar >CC: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com >Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. >Date: Wed, 9 Jan 2002 19:12:49 -0800 (PST) > > > I interpret it as 'don't use timestmaps in a unidirectional way'. > >Hmmm, a TCP connection is always bidirectional. And the option has >to be negotiated by both sides. What do you really mean by >"unidirectional?" > > > Besides, I don't know of a TCP which would reject segments it receives >on a > > timestamp negotiated connection just because it does not have >timestamps. > > From what you said, Solaris also accepts such segments. The rest of the > > interpretation seems to be Solaris specific. > >It seems that you misinterpreted my comment. My comment is about >ignoring the timestamp option, not rejecting segments. This is >a major difference. And the other comment is that I don't know of >any implementation which does not send timestamp option in every >segment (besides, for example, RST) once it is negotiated at the >beginning. And for the sake of the RTTM and PAWS, I believe it >is safe to assume that if one side suddenly stops sending timestamp >option, there must be something wrong and RTTM and PAWS will not >be reliable. > > > As I suggested earlier, if PAWS check is necessary (easy to figure out >for > > the sender), every segment should be timestamped. For RTTM, timestamping >and > > taking an RTT measurement on every segment is really an overkill in a >lot of > > cases. > >Hmmm, when you say it is easy to figure out whether PAWS is needed, >can you explain further? Nowadays, I believe most computers have >100Mbps NIC (I believe soon all gadgets with network connection will >be like that). RFC 1323 clearly states the problem here. So are >you saying that all connections should use PAWS then? I believe >you are not suggesting that. Maybe you can explain your easy method. >And can you also explain how you can tell taking an RTT measurement on >every segment is an overkill at the beginning of a connection? > > > In my opinion, the primary reason why TCP-clients do not negotiate a > > timestamp option today is the constant overhead in terms of bandwidth it > > causes. If this were to be on a need only basis (like SACK), it would > > probably be more widely negotiated and it would enable wide spread > > deployment of Eifel-capable TCPs (probably, every mobile node would > > negotiate timestamps!). > >Well, assuming that timestamp option is really rarely used nowadays, >I believe there can be many other reasons... Not all stacks support >timestamp option (there are still many old stacks out there...). >The option is not turned on be default. ... Honestly, given today's >network and ROHC for slow links, the 12 bytes overhead is really nothing >for most people... This is my own conjecture without support. If >you can substantiate your own overhead conjecture, I'll buy it (-: > > K. Poon. > kcpoon@eng.sun.com > > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 07:51:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13769 for ; Thu, 10 Jan 2002 07:51:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25085 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 07:51:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24046; Thu, 10 Jan 2002 07:13:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24017 for ; Thu, 10 Jan 2002 07:12:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13426 for ; Thu, 10 Jan 2002 07:12:54 -0500 (EST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0ACCOF25798; Thu, 10 Jan 2002 04:12:24 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAR77148; Thu, 10 Jan 2002 04:12:23 -0800 (PST) Message-ID: <3C3D8527.E7B4B0BB@stewart.chicago.il.us> Date: Thu, 10 Jan 2002 06:12:23 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: Douglas Otis , Tsvwg Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-01.txt References: <3C3CE66F.411905C8@cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: > > An important normative reference is missing in the checksum draft - > [RFC2960] :-) > > -Qiaobing > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg Thanks Q I already caught that after Scott pointed out to me the missing RFC2129 reference as well :-0 (Plus the draft identifies itself as RFC2960 ... cut and paste errors that creep in are so much fun :-) R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 08:02:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13887 for ; Thu, 10 Jan 2002 08:02:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25657 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 08:02:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24828; Thu, 10 Jan 2002 07:33:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24793 for ; Thu, 10 Jan 2002 07:33:57 -0500 (EST) Received: from lawyers.grc.nasa.gov (d254.as0.clev.oh.voyager.net [216.214.12.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13691 for ; Thu, 10 Jan 2002 07:33:54 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id HAA32354; Thu, 10 Jan 2002 07:33:02 -0500 Message-Id: <200201101233.HAA32354@lawyers.grc.nasa.gov> To: "sanjay kaniyar" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: gurtov@cs.helsinki.fi, tsvwg@ietf.org, Reiner.Ludwig@ericsson.com Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Organization: BBN Technologies/NASA GRC Song-of-the-Day: Who Are You Date: Thu, 10 Jan 2002 07:33:02 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Two points... Repacketization seems like it will be a problem. In other words, adding 12 bytes to a retransmit turns a single packet retransmission into two packets worth of data when sending full sized segments. While this should not be a problem in principle, my guess is that it would end up being quite an ugly situation (because hosts would be sending too many segments, runt segments, etc. and because middle boxes may puke). If we want a signaling method for retransmits, I say we revert to the bit approach. > My argument is that, there should be allowance (and specification) > for using timestamps only when it is necessary/useful to do so > (just like SACK). The Eifel draft seems to me like a good place to > address this (as well as the= suggestion about restarting the > retransmit timer after fast-retransmit)? I agree that there could well be cases for enabling timestamps on the fly (e.g., enable them for all connections, but only use them once we are sending fast enough to need PAWS). However, I disagree completely with the assertion that the eifel draft is the right place to make that change. Eifel is simply an algorithm to detect spurious timeouts. Let's not throw together everything in the one draft. OK, I lied... One more point... If you (a) don't want to incur the overhead of timestamps and (b) want to detect spurious retransmits, you *do* have another option. You can use DSACK to detect spurious retransmits. For instance, there is an algorithm sketched in draft-blanton-dsack-use-01.txt that could be used. It is not nearly as robust as eifel, but my hit is that it could work pretty well in lots of cases. allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 08:29:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14113 for ; Thu, 10 Jan 2002 08:29:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26081 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 08:29:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25760; Thu, 10 Jan 2002 08:08:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25727 for ; Thu, 10 Jan 2002 08:08:20 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13913 for ; Thu, 10 Jan 2002 08:08:17 -0500 (EST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0AD7Ok19490; Thu, 10 Jan 2002 05:07:24 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAR77485; Thu, 10 Jan 2002 05:07:46 -0800 (PST) Message-ID: <3C3D9221.F6B20665@stewart.chicago.il.us> Date: Thu, 10 Jan 2002 07:07:46 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: "Kimble Scott (NET/MtView)" , tsvwg@ietf.org Subject: Re: [Tsvwg] Section 4.1.9 sctpsocket-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Kacheong: Sorry for my delayed answer... I have taken Scott's advise for our next pass since getsockname() returns the LOCAL address of the endpoint. I believe this works on both TCP and UPD sockets in most API's given back the bound endpoint address. The one that gets the peer address would be one that we would need to have just for the TCP model... R Kacheong Poon wrote: > > Sorry for the late reply. I was on vacation the last month... > > > Section 4.1.9 sctpsocket-02.txt > > > > getsockname() is applicable to both TCP-Style and UDP-Style SCTP > > instances. Section 4.1.9 can be moved to section 6. > > Can you explain why? For UDP-style socket, an fd is associated > with many associations. And the different associations may actually > have different local info. If getsockname() is applied to a UDP-style > socket, which associations' local info should be returned? > > K. Poon. > kcpoon@eng.sun.com > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 10:03:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15842 for ; Thu, 10 Jan 2002 10:03:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29839 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 10:03:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28938; Thu, 10 Jan 2002 09:39:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28862 for ; Thu, 10 Jan 2002 09:39:36 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15598 for ; Thu, 10 Jan 2002 09:39:34 -0500 (EST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0AEcRJ06376; Thu, 10 Jan 2002 06:38:27 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAR78216; Thu, 10 Jan 2002 06:38:26 -0800 (PST) Message-ID: <3C3DA762.C767295D@stewart.chicago.il.us> Date: Thu, 10 Jan 2002 08:38:26 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Douglas Otis CC: Tsvwg Subject: Re: [Tsvwg] RE: Working Group Last Call on SCTP checksum change References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Doug: These look real good, I have put them in the forming -02 version with the addition of: - Fixed references for 2119 and 2960 - Fixed some \n\r issues (corrected by good ole dos2unix). - A commented pointed out by Matt Crawford (offline): in the abstract the statement: "For small packets, this provides weak protection against the detection of errors." is a bit unclear :> I think that changing it to: "For small packets Adler-32 provides weak detection of errors." makes it a bit more concise :>> R Douglas Otis wrote: > > This could be used to update the draft to satisfy the missing sections: > > 3 Security Considerations > > There may be a computational advantage in validating the Association against > the Verification Tag prior to performing a checksum as invalid tags will > result in the same action as a bad checksum in most cases. The exceptions > for this technique would be INIT and some SHUTDOWN-COMPLETE exchanges as > well as a stale COOKIE-ECHO. These special case exchanges must represent > small packets and will minimize the effect of the checksum calculation. > > 4 IANA Considerations > > There are no IANA considerations required in this document. > > Doug > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 10:11:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15965 for ; Thu, 10 Jan 2002 10:11:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00094 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 10:11:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28840; Thu, 10 Jan 2002 09:39:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28811 for ; Thu, 10 Jan 2002 09:39:07 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15591 for ; Thu, 10 Jan 2002 09:39:04 -0500 (EST) From: Ivan.Arias-Rodriguez@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0AEce905712 for ; Thu, 10 Jan 2002 16:38:40 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Jan 2002 16:38:39 +0200 Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 10 Jan 2002 16:38:39 +0200 Message-ID: <58AEDE27D48F884285007ABF827FF26308EE16@esebe017.NOE.Nokia.com> To: LyOng@ciena.com, tsvwg@ietf.org Cc: audrey@vanb.com, steven.glass@sun.com Subject: RE: [Tsvwg] SCTP testing at Connectathon Date: Thu, 10 Jan 2002 16:38:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Hi all! I might be interested. However, I have checked the Connectathon web page and it seems that every participant has the right to use only one Ethernet socket... In that case it won't be possible to test multihoming... I don't really know much about this, so I don't know if it would be possible to carry your own hub or something so you are able to use at least two Ethernet cards at the same time... Could somebody tell me how to solve this problem? Moreover, I'm not sure of what is the total amount that should be paid... I mean, let's say I'm going there alone, so I should pay 2,300$ for the station (if I do it before January 15th), plus 300$ of the engineer fee, plus probably something more since I will surely need 220V electrical power (don't know if I could find a 110V AC adapter)... Am I right? Thanks! > -----Original Message----- > From: ext Ong, Lyndon [mailto:LyOng@ciena.com] > Sent: 20. December 2001 21:05 > To: tsvwg@ietf.org > Cc: audrey@vanb.com; steven.glass@sun.com > Subject: [Tsvwg] SCTP testing at Connectathon > > > Folks, > > For those interested, we are planning to have SCTP testing as part of > Connectathon > at end February/beginning March 2002. Steven Glass at Sun > has volunteered > to > coordinate. He and Audrey Van Belleghem (steven.glass@sun.com and > audrey@vanb.com) > would like to get a count of the number of people interested in > participating, so please > send them an email if you are interested. > > More information on Connectathon is at http://www.connectathon.org. > > Since this is being set up a bit late, my understanding is that the > discounted registration > cutoff may be extended for the SCTP testing participants. > > Cheers, > > Lyndon Ong > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 10:18:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16104 for ; Thu, 10 Jan 2002 10:18:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00221 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 10:18:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29244; Thu, 10 Jan 2002 09:51:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29215 for ; Thu, 10 Jan 2002 09:51:33 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15728 for ; Thu, 10 Jan 2002 09:51:30 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA08264; Thu, 10 Jan 2002 15:51:12 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA26081; Thu, 10 Jan 2002 15:51:13 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 15:51:12 +0100 Message-ID: From: Tuexen Michael To: "'Ivan.Arias-Rodriguez@nokia.com'" , LyOng@ciena.com, tsvwg@ietf.org Cc: audrey@vanb.com, steven.glass@sun.com Subject: RE: [Tsvwg] SCTP testing at Connectathon Date: Thu, 10 Jan 2002 15:50:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Dear Ivan, the setup of the test bed is currently being discussed. I hope that connecthaton can provide a setup similiar to the one used at the earlier bakeoffs. This would mean that you have two connections (two ethernet plugs) to two different IP networks. So you can really test multihoming and that stuff... The prices you mentioned are correct (in my interpretation of the website). Maybe someone from Sun can make a statement. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN WN CS SE 5 E-mail: Michael.Tuexen@icn.siemens.de > -----Original Message----- > From: Ivan.Arias-Rodriguez@nokia.com [SMTP:Ivan.Arias-Rodriguez@nokia.com] > Sent: Thursday, January 10, 2002 3:39 PM > To: LyOng@ciena.com; tsvwg@ietf.org > Cc: audrey@vanb.com; steven.glass@sun.com > Subject: RE: [Tsvwg] SCTP testing at Connectathon > > Hi all! > > I might be interested. However, I have checked the Connectathon > web page and it seems that every participant has the right to use only > one Ethernet socket... In that case it won't be possible to test > multihoming... > > I don't really know much about this, so I don't know if it would > be possible to carry your own hub or something so you are able to use at > least two Ethernet cards at the same time... > > Could somebody tell me how to solve this problem? > > Moreover, I'm not sure of what is the total amount that should > be paid... I mean, let's say I'm going there alone, so I should pay > 2,300$ for the station (if I do it before January 15th), plus 300$ of > the engineer fee, plus probably something more since I will surely need > 220V electrical power (don't know if I could find a 110V AC adapter)... > Am I right? > > Thanks! > > > -----Original Message----- > > From: ext Ong, Lyndon [mailto:LyOng@ciena.com] > > Sent: 20. December 2001 21:05 > > To: tsvwg@ietf.org > > Cc: audrey@vanb.com; steven.glass@sun.com > > Subject: [Tsvwg] SCTP testing at Connectathon > > > > > > Folks, > > > > For those interested, we are planning to have SCTP testing as part of > > Connectathon > > at end February/beginning March 2002. Steven Glass at Sun > > has volunteered > > to > > coordinate. He and Audrey Van Belleghem (steven.glass@sun.com and > > audrey@vanb.com) > > would like to get a count of the number of people interested in > > participating, so please > > send them an email if you are interested. > > > > More information on Connectathon is at http://www.connectathon.org. > > > > Since this is being set up a bit late, my understanding is that the > > discounted registration > > cutoff may be extended for the SCTP testing participants. > > > > Cheers, > > > > Lyndon Ong > > > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/tsvwg > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 10:33:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16415 for ; Thu, 10 Jan 2002 10:33:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00913 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 10:33:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00073; Thu, 10 Jan 2002 10:10:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00042 for ; Thu, 10 Jan 2002 10:10:53 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15951 for ; Thu, 10 Jan 2002 10:10:51 -0500 (EST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0AF9pk01816; Thu, 10 Jan 2002 07:09:51 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAR78629; Thu, 10 Jan 2002 07:10:12 -0800 (PST) Message-ID: <3C3DAED3.D9B7662E@stewart.chicago.il.us> Date: Thu, 10 Jan 2002 09:10:11 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "'Ivan.Arias-Rodriguez@nokia.com'" CC: Tuexen Michael , LyOng@ciena.com, tsvwg@ietf.org, audrey@vanb.com, steven.glass@sun.com Subject: Re: [Tsvwg] SCTP testing at Connectathon References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Ivan: One side note to add here.. I would hope they WILL provide 110v power.. I am depending on it! So if your computer can take 110v then all you need do is bring an adaptor to plug in to your power supply. But you better double check the power supply allows input from 110-220 (like my laptop does). I know some don't and I have seen some PC's be smoked by a incorrect plug in :> R Tuexen Michael wrote: > > Dear Ivan, > > the setup of the test bed is currently being discussed. > I hope that connecthaton can provide a setup similiar to > the one used at the earlier bakeoffs. This would mean that you > have two connections (two ethernet plugs) to two different > IP networks. So you can really test multihoming and that > stuff... > > The prices you mentioned are correct (in my interpretation > of the website). Maybe someone from Sun can make a statement. > > Best regards > Michael > > Michael Tuexen Tel.: +49 89 722 47210 > Siemens AG Fax: +49 89 722 48212 > ICN WN CS SE 5 E-mail: Michael.Tuexen@icn.siemens.de > > > -----Original Message----- > > From: Ivan.Arias-Rodriguez@nokia.com [SMTP:Ivan.Arias-Rodriguez@nokia.com] > > Sent: Thursday, January 10, 2002 3:39 PM > > To: LyOng@ciena.com; tsvwg@ietf.org > > Cc: audrey@vanb.com; steven.glass@sun.com > > Subject: RE: [Tsvwg] SCTP testing at Connectathon > > > > Hi all! > > > > I might be interested. However, I have checked the Connectathon > > web page and it seems that every participant has the right to use only > > one Ethernet socket... In that case it won't be possible to test > > multihoming... > > > > I don't really know much about this, so I don't know if it would > > be possible to carry your own hub or something so you are able to use at > > least two Ethernet cards at the same time... > > > > Could somebody tell me how to solve this problem? > > > > Moreover, I'm not sure of what is the total amount that should > > be paid... I mean, let's say I'm going there alone, so I should pay > > 2,300$ for the station (if I do it before January 15th), plus 300$ of > > the engineer fee, plus probably something more since I will surely need > > 220V electrical power (don't know if I could find a 110V AC adapter)... > > Am I right? > > > > Thanks! > > > > > -----Original Message----- > > > From: ext Ong, Lyndon [mailto:LyOng@ciena.com] > > > Sent: 20. December 2001 21:05 > > > To: tsvwg@ietf.org > > > Cc: audrey@vanb.com; steven.glass@sun.com > > > Subject: [Tsvwg] SCTP testing at Connectathon > > > > > > > > > Folks, > > > > > > For those interested, we are planning to have SCTP testing as part of > > > Connectathon > > > at end February/beginning March 2002. Steven Glass at Sun > > > has volunteered > > > to > > > coordinate. He and Audrey Van Belleghem (steven.glass@sun.com and > > > audrey@vanb.com) > > > would like to get a count of the number of people interested in > > > participating, so please > > > send them an email if you are interested. > > > > > > More information on Connectathon is at http://www.connectathon.org. > > > > > > Since this is being set up a bit late, my understanding is that the > > > discounted registration > > > cutoff may be extended for the SCTP testing participants. > > > > > > Cheers, > > > > > > Lyndon Ong > > > > > > > > > _______________________________________________ > > > tsvwg mailing list > > > tsvwg@ietf.org > > > http://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 11:09:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17358 for ; Thu, 10 Jan 2002 11:09:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02245 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 11:09:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01267; Thu, 10 Jan 2002 10:45:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01238 for ; Thu, 10 Jan 2002 10:45:13 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16690 for ; Thu, 10 Jan 2002 10:45:10 -0500 (EST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0AFjAJ25695; Thu, 10 Jan 2002 16:45:10 +0100 (MET) Received: from res0010384da36.ericsson.com (dhcp5-66 [164.48.135.66]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id QAA23413; Thu, 10 Jan 2002 16:45:06 +0100 (MET) Message-Id: <5.1.0.14.0.20020110163120.01ba2e98@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Jan 2002 16:45:59 +0100 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Cc: "sanjay kaniyar" , gurtov@cs.helsinki.fi, tsvwg@ietf.org, Reiner.Ludwig@ericsson.com In-Reply-To: <200201101233.HAA32354@lawyers.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org I haven't caught up in this discussion yet, but one comment ... At 13:33 10.01.2002, Mark Allman wrote: >If you (a) don't want to incur the overhead of timestamps and (b) >want to detect spurious retransmits, you *do* have another option. >You can use DSACK to detect spurious retransmits. If you want to detect a spurious retransmit caused by a spurious timeout, you typically want to do that so that you can avoid that the entire outstanding flight of segments is (often unnecessarily) retransmitted. This "go-back-N misbehavior" inevitably follows a spurious timeout. However, you *cannot* use DSACK to avoid those go-back-N retransmits since the DSACK only arrives after the "go-back-N misbehavior" has already taken place. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 11:11:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17434 for ; Thu, 10 Jan 2002 11:11:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02330 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 11:11:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01548; Thu, 10 Jan 2002 10:53:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01521 for ; Thu, 10 Jan 2002 10:53:28 -0500 (EST) Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16962 for ; Thu, 10 Jan 2002 10:53:26 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id D5385640C3; Thu, 10 Jan 2002 10:52:48 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAN8a4Gc; Thu, 10 Jan 02 10:52:48 -0500 Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA25080; Thu, 10 Jan 2002 10:52:48 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA18740; Thu, 10 Jan 2002 10:52:48 -0500 (EST) Message-Id: <200201101552.KAA18740@guns.lerc.nasa.gov> To: Reiner Ludwig From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "sanjay kaniyar" , gurtov@cs.Helsinki.FI, tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Organization: BBN Technologies/NASA GRC Song-of-the-Day: Who Are You Date: Thu, 10 Jan 2002 10:52:48 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > >If you (a) don't want to incur the overhead of timestamps and (b) > >want to detect spurious retransmits, you *do* have another > >option. You can use DSACK to detect spurious retransmits. > > If you want to detect a spurious retransmit caused by a spurious > timeout, you typically want to do that so that you can avoid that > the entire outstanding flight of segments is (often unnecessarily) > retransmitted. This "go-back-N misbehavior" inevitably follows a > spurious timeout. > > However, you *cannot* use DSACK to avoid those go-back-N > retransmits since the DSACK only arrives after the "go-back-N > misbehavior" has already taken place. Yes. But, if you can detect a spurious retransmit (and go-back-n misbehavior) you can avoid it in the future. So, there is still value in detection no matter when you do so. I am not saying that use of the DSACK method is *preferred*. I am simply noting that if someone does not want to incur the cost of using timestamps and eifel there is still *something* that can be done. allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 11:38:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18448 for ; Thu, 10 Jan 2002 11:38:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03710 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 11:38:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02669; Thu, 10 Jan 2002 11:20:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02640 for ; Thu, 10 Jan 2002 11:20:12 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17814 for ; Thu, 10 Jan 2002 11:20:09 -0500 (EST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0AGJeF00347; Thu, 10 Jan 2002 08:19:40 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAR79731; Thu, 10 Jan 2002 08:19:39 -0800 (PST) Message-ID: <3C3DBF1A.6F725E93@stewart.chicago.il.us> Date: Thu, 10 Jan 2002 10:19:38 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: TSV WG list , sigtran-test Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP ref impl update Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Hi All: I just put up on the http://www.sctp.org web site the 4.0.5 version of the reference implementation. It DOES not include the new crc32c algorithm... and is the same one available in the SCTP book. It does contain: - Numerous bug fixes - Fully functional Add-ip - Fully functional u-sctp Regards R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 12:39:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19946 for ; Thu, 10 Jan 2002 12:39:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07380 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 12:39:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05890; Thu, 10 Jan 2002 12:09:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05856 for ; Thu, 10 Jan 2002 12:08:58 -0500 (EST) Received: from virtual4.dsldesigns.com (IDENT:root@[216.83.40.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19337 for ; Thu, 10 Jan 2002 12:08:55 -0500 (EST) Received: from vanb.com ([198.79.111.50]) by virtual4.dsldesigns.com (8.11.1/8.11.1) with ESMTP id g0AHufL22349; Thu, 10 Jan 2002 09:56:41 -0800 Message-ID: <3C3DC90D.79C5177A@vanb.com> Date: Thu, 10 Jan 2002 09:02:05 -0800 From: Audrey Van Belleghem Reply-To: audrey@vanb.com Organization: Van Belleghem Corporation X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: LyOng@ciena.com, tsvwg@ietf.org, steven.glass@sun.com Subject: Re: [Tsvwg] SCTP testing at Connectathon References: <58AEDE27D48F884285007ABF827FF26308EE16@esebe017.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit Hi Ivan, The Connectathon drops are defined by station size. One drop for a single station, 2 drops for a small, etc. You are allowed to bring a hub if you need to expand your drops. Nokia is already registered as a participant (I can put you in touch with the right people there), so you would only need to see if they have space in their station for one additional person. If so, you only need to pay the $300 engineer fee. If you need 220V, there is an additional charge to provide that power to you. I would need your NEMA number, voltage requirement, and single or 3-phase information to provide the quote from the electrician (the cost comes straight from them but we handle the transaction). Thanks for your interest! Yes, deadline for early discount is Jan. 15th. Audrey Ivan.Arias-Rodriguez@nokia.com wrote: > Hi all! > > I might be interested. However, I have checked the Connectathon > web page and it seems that every participant has the right to use only > one Ethernet socket... In that case it won't be possible to test > multihoming... > > I don't really know much about this, so I don't know if it would > be possible to carry your own hub or something so you are able to use at > least two Ethernet cards at the same time... > > Could somebody tell me how to solve this problem? > > Moreover, I'm not sure of what is the total amount that should > be paid... I mean, let's say I'm going there alone, so I should pay > 2,300$ for the station (if I do it before January 15th), plus 300$ of > the engineer fee, plus probably something more since I will surely need > 220V electrical power (don't know if I could find a 110V AC adapter)... > Am I right? > > Thanks! > > > -----Original Message----- > > From: ext Ong, Lyndon [mailto:LyOng@ciena.com] > > Sent: 20. December 2001 21:05 > > To: tsvwg@ietf.org > > Cc: audrey@vanb.com; steven.glass@sun.com > > Subject: [Tsvwg] SCTP testing at Connectathon > > > > > > Folks, > > > > For those interested, we are planning to have SCTP testing as part of > > Connectathon > > at end February/beginning March 2002. Steven Glass at Sun > > has volunteered > > to > > coordinate. He and Audrey Van Belleghem (steven.glass@sun.com and > > audrey@vanb.com) > > would like to get a count of the number of people interested in > > participating, so please > > send them an email if you are interested. > > > > More information on Connectathon is at http://www.connectathon.org. > > > > Since this is being set up a bit late, my understanding is that the > > discounted registration > > cutoff may be extended for the SCTP testing participants. > > > > Cheers, > > > > Lyndon Ong > > > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 20:24:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27226 for ; Thu, 10 Jan 2002 20:24:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22304 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 20:24:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21974; Thu, 10 Jan 2002 20:02:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21948 for ; Thu, 10 Jan 2002 20:02:34 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26967 for ; Thu, 10 Jan 2002 20:02:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08334; Thu, 10 Jan 2002 18:02:32 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA09026; Thu, 10 Jan 2002 17:02:31 -0800 (PST) Date: Thu, 10 Jan 2002 17:01:51 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. To: sanjay kaniyar Cc: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > 1. Data transfer could be unidirectional, in which case timestamps would > only be necessary for the direction of data flow. Somewhere in the 1323, > they mention that they chose to 'always' use it bidirectionally for the > purpose of simplicity etc. Hmm, are you saying that one side sets the timestamp option and the other side does not echo it back? Can you be more specific on exactly the format you are talking about? Have you thought about the mechanism you are proposing? Are you trying to come up with a new timestamp option for unidirectional transfer? Please tell us more how it should work. > 2. I did not misinterpret your comment, I understood that Solaris does not > reject segments without timestamps. My point is that, the behavior of > 'considering the peer to be not able to generate timestamps accurately just > because some segments did not have timestamps' is what is Solaris speicific. Point taken. > 3. It may not be necessary to time every segment in cases like, for example, > where it does not change much at all? or maybe timing every 3rd segment is > just as good? or maybe it is too small and the sender TCP is going to stick > to its attainable minimum? > > 4. It is possible to say a connection does not need PAWS check based on the > perceived RTT and the advertised receive window size, for example. Or if > there is a limit set on the maximum bandwidth a connection can use etc. I guess you didn't answer my questions at all. How do you know at the connection setup time that timestamp should be used ? TCP knows nothing about RTT (well, maybe temporal sharing of some info from a previous connection can help), the other side's advertised window (active opening), ... And I believe you missed the reason for PAWS, it has to do with the maximum transfer bandwidth, not really RTT related, and is not easy to measure at the end host... And I believe you agreed that for PAWS to work, every segments need to have the timestamp option. So how should your proposed change to use timestamp option for retransmission indication work? You should think more about what you are proposing before you can say that it is easy to do (there are too many maybes in your statements...). Please remove those maybes and state exactly when RTTM is an overkill and show us how this can be determined at connection setup time. Also note that whether a TCP stack makes use of all RTT samples to calculate RTO and which samples to use can be an implementation choice. > 5. Whether 12 bytes in each segment and ack is an overhead or not (with ROHC > or without) is quite subjective, I think. To me, a single byte that goes on > the wire that does not have any purpose to it is an overhead and should be > avoided if it is not too much of an engineering overhead (and I believe with > timestamps it is not). In what way does this "engineering decision" support your comment about the main reason of limited use of timestamp option? Honestly, I don't know if it is really of limited use or not. Maybe you can show us the data. And please show us what you meant by "not much of an engineering overhead." That is the exact way of how your proposal works. K. Poon. kcpoon@eng.sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 20:45:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27475 for ; Thu, 10 Jan 2002 20:45:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA23034 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 20:45:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22375; Thu, 10 Jan 2002 20:27:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22350 for ; Thu, 10 Jan 2002 20:27:13 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27257 for ; Thu, 10 Jan 2002 20:27:10 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19843; Thu, 10 Jan 2002 18:27:11 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA16247; Thu, 10 Jan 2002 17:27:10 -0800 (PST) Date: Thu, 10 Jan 2002 17:26:29 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. To: mallman@grc.nasa.gov Cc: Reiner Ludwig , sanjay kaniyar , gurtov@cs.Helsinki.FI, tsvwg@ietf.org In-Reply-To: "Your message with ID" <200201101552.KAA18740@guns.lerc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > Yes. But, if you can detect a spurious retransmit (and go-back-n > misbehavior) you can avoid it in the future. So, there is still > value in detection no matter when you do so. I am not saying that > use of the DSACK method is *preferred*. I am simply noting that if > someone does not want to incur the cost of using timestamps and > eifel there is still *something* that can be done. But how does one spurious timeout correlate to the next timeout? I don't know how TCP can say the next timeout must be spurious given that the previous one is... K. Poon. kcpoon@eng.sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 22:19:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29394 for ; Thu, 10 Jan 2002 22:19:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA25500 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 22:19:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24808; Thu, 10 Jan 2002 21:57:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24777 for ; Thu, 10 Jan 2002 21:57:48 -0500 (EST) Received: from hotmail.com (f52.law3.hotmail.com [209.185.241.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29188 for ; Thu, 10 Jan 2002 21:57:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 Jan 2002 18:57:11 -0800 Received: from 207.46.137.9 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 11 Jan 2002 02:57:10 GMT X-Originating-IP: [207.46.137.9] From: "sanjay kaniyar" To: kcpoon@eng.sun.com Cc: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Date: Thu, 10 Jan 2002 18:57:10 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jan 2002 02:57:11.0968 (UTC) FILETIME=[AAAB9200:01C19A4B] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org 1. Timestamps are bidirectional in the sense that in a segment going from A->B, there are 2 of them: 1:generated by A, 2:echoed value, sent by B originally. If the connection is doing unidirectional data transfer entirely, it is sufficient to have timestamps generated and sent by the sender in the data segments and acknowledgements echo them in the other direction. This is what RFC 1323 referred to as 'unidirectional use of timestamps'. They chose to 'always use timestamps bidirectionally' instead because of reasons like simplicity etc. There is nothing new I am proposing here. I only quoted this to rebut your claim - 'always refers sending timestamps in each segment'. 3 & 4. (a) I did answer your question. I never said it is always possible to figure out whether it is possible to figure out whether timestamps are necessary at the connection set up time (nor is it the problem I am trying to solve). All I am trying to do is to timestamp (and echo) segments on a connection which has timestamps negotiated on it only when it is necessary and useful, I said nothing about figuruing out whenther they should be negotiated or not. (b) I know that to do PAWS check, every segment needs to be timstamped. However, to figure out whether PAWS check needs to be done or not, can be implementation specific because there can be many reasons within the perview of TCP or outside of it which could contribute to this. Note that, for a connection to require PAWS check it has to (i) have a transfer rate of greater than a threshold and (ii) have a life time greater than a threhold. If it is possible to determine one of these is not going to be met, there is no need to do PAWS on that connection. The maybe's were actually examples of such instances: - A bandwidth limit is imposed on each connection {(i) fails} - Connections are always secured with IPSEC, which has anti-replay protection. - A timestamp negotiated connection starts with the assumption that PAWS is necessary at the peer and timestamps every segment to begin with. After it has an estimate of the RTT, it figures out (i) will fail because the maximum transfer rate is limited by the bandwidth-delay product. - The sending application did a graceful close after submitting a buffer which is smaller than what is takes to cover the sequence space. - A mail server admin knows each client has a mailbox size maximum of 1 gigabytes and there is no danger of wrap around when a mail client tries to download it. My point is that, this is really something that can't be put in a spec, but chosen by many factors. (c) Again, determining whehter timestamping every segment for RTTM is an overkill or not should be an implemenation choice. Examples being: - The timer on the sender TCP has a granularity of 100 ms and the first 10 RTT measurements are all below 50 seconds. - The last 10 RTT measurements did not vary by more than 5%. 5. My suggestion was, if a sender TCP is able to figure this out, it can selectively use timestamps. If the receiver also adheres to some well known rule, it would save sending some extra bytes in either direction. The rule is what I thought could be part of Eifel draft, as it was using timestamps in a way other than RTTM and PAWS, and could be achieved wihtout timestamping every segment. You might already have seen the following: Sender-TCP would put a timestamp in a segment if: * PAWS protection is necessary for the connection. * An RTT measurement using timestamps is desired, and one such measurement is in progress. We consider a measurement to be in progress if sender has sent a timestamp after it started a measurement and it is not yet echoed back. * Retransmission of a segment upon timeout. Receiver-TCP would put a timestamp (or echo what it got) in an ack if: * no more than 3 acks have been sent after any segment with a timestamp was received. Sanjay. >From: Kacheong Poon >Reply-To: Kacheong Poon >To: sanjay kaniyar >CC: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com >Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. >Date: Thu, 10 Jan 2002 17:01:51 -0800 (PST) > > > 1. Data transfer could be unidirectional, in which case timestamps would > > only be necessary for the direction of data flow. Somewhere in the 1323, > > they mention that they chose to 'always' use it bidirectionally for the > > purpose of simplicity etc. > >Hmm, are you saying that one side sets the timestamp option and the >other side does not echo it back? Can you be more specific on exactly >the format you are talking about? Have you thought about the mechanism >you are proposing? Are you trying to come up with a new timestamp option >for unidirectional transfer? Please tell us more how it should work. > > > 2. I did not misinterpret your comment, I understood that Solaris does >not > > reject segments without timestamps. My point is that, the behavior of > > 'considering the peer to be not able to generate timestamps accurately >just > > because some segments did not have timestamps' is what is Solaris >speicific. > >Point taken. > > > 3. It may not be necessary to time every segment in cases like, for >example, > > where it does not change much at all? or maybe timing every 3rd segment >is > > just as good? or maybe it is too small and the sender TCP is going to >stick > > to its attainable minimum? > > > > 4. It is possible to say a connection does not need PAWS check based on >the > > perceived RTT and the advertised receive window size, for example. Or if > > there is a limit set on the maximum bandwidth a connection can use etc. > >I guess you didn't answer my questions at all. How do you know at >the connection setup time that timestamp should be used ? TCP >knows nothing about RTT (well, maybe temporal sharing of some info from >a previous connection can help), the other side's advertised window >(active opening), ... And I believe you missed the reason for PAWS, it >has to do with the maximum transfer bandwidth, not really RTT related, and >is not easy to measure at the end host... And I believe you agreed that >for PAWS to work, every segments need to have the timestamp option. So >how should your proposed change to use timestamp option for retransmission >indication work? > >You should think more about what you are proposing before you can say >that it is easy to do (there are too many maybes in your statements...). >Please remove those maybes and state exactly when RTTM is an overkill and >show us how this can be determined at connection setup time. Also note >that >whether a TCP stack makes use of all RTT samples to calculate RTO and which >samples to use can be an implementation choice. > > > 5. Whether 12 bytes in each segment and ack is an overhead or not (with >ROHC > > or without) is quite subjective, I think. To me, a single byte that goes >on > > the wire that does not have any purpose to it is an overhead and should >be > > avoided if it is not too much of an engineering overhead (and I believe >with > > timestamps it is not). > >In what way does this "engineering decision" support your comment about >the main reason of limited use of timestamp option? Honestly, I don't >know if it is really of limited use or not. Maybe you can show us the >data. And please show us what you meant by "not much of an engineering >overhead." That is the exact way of how your proposal works. > > K. Poon. > kcpoon@eng.sun.com > > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >http://www1.ietf.org/mailman/listinfo/tsvwg _________________________________________________________________ Join the world뭩 largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 23:24:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00979 for ; Thu, 10 Jan 2002 23:24:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA05937 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 23:24:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05780; Thu, 10 Jan 2002 23:10:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05755 for ; Thu, 10 Jan 2002 23:10:51 -0500 (EST) Received: from lawyers.grc.nasa.gov (d134.as0.clev.oh.voyager.net [209.81.165.135]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00872 for ; Thu, 10 Jan 2002 23:10:49 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id XAA01325; Thu, 10 Jan 2002 23:08:26 -0500 Message-Id: <200201110408.XAA01325@lawyers.grc.nasa.gov> To: Kacheong Poon From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: Reiner Ludwig , sanjay kaniyar , gurtov@cs.Helsinki.FI, tsvwg@ietf.org Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lawyers, Guns and Money Date: Thu, 10 Jan 2002 23:08:26 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > > Yes. But, if you can detect a spurious retransmit (and go-back-n > > misbehavior) you can avoid it in the future. So, there is still > > value in detection no matter when you do so. I am not saying that > > use of the DSACK method is *preferred*. I am simply noting that if > > someone does not want to incur the cost of using timestamps and > > eifel there is still *something* that can be done. > > But how does one spurious timeout correlate to the next timeout? > I don't know how TCP can say the next timeout must be spurious > given that the previous one is... Oh, you can't. (Or, at least it is not obvious to me that you can.) What I meant was that if you know you took a spurious timeout (or did a needless fast retransmit) you can take that as an indication that your estimator is not working as well as you might like (i.e., the RTO is not waiting long enough for an ACK to return). So, you can tweak the estimator somehow (or alter the dup ack threshold somehow) in an attempt to come up with a better trigger for determining loss so that maybe you can prevent further spurious retransmits (and the resulting negative behavior). allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 23:25:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01008 for ; Thu, 10 Jan 2002 23:25:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA05971 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 23:25:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05742; Thu, 10 Jan 2002 23:09:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05709 for ; Thu, 10 Jan 2002 23:09:26 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00864 for ; Thu, 10 Jan 2002 23:09:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15639; Thu, 10 Jan 2002 21:09:25 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA18665; Thu, 10 Jan 2002 20:09:24 -0800 (PST) Date: Thu, 10 Jan 2002 20:08:44 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. To: sanjay kaniyar Cc: tsvwg@ietf.org, Reiner.Ludwig@ericsson.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org > 1. Timestamps are bidirectional in the sense that in a segment going from > A->B, there are 2 of them: 1:generated by A, 2:echoed value, sent by B > originally. If the connection is doing unidirectional data transfer > entirely, it is sufficient to have timestamps generated and sent by the > sender in the data segments and acknowledgements echo them in the other > direction. This is what RFC 1323 referred to as 'unidirectional use of > timestamps'. > > They chose to 'always use timestamps bidirectionally' instead because of > reasons like simplicity etc. There is nothing new I am proposing here. I > only quoted this to rebut your claim - 'always refers sending timestamps in > each segment'. Correct me if I am wrong, your problem with the current timestamp option is that it takes up 12 bytes. Now in your "unidirectional" timestamp scenario, isn't it true that the 12 bytes timestamp option is still in every segments in both directions even if only the data sender chooses to use it? Note that I never mentioned that "unidirectional timestamp option" is not possible. I am trying to say that the current timestamp option, with both time and echo value in it, works in a specific way. It is designed to be used for both sides. You can come up with your own "unidirectional timestamp option." But it is just not the same as RFC 1323.... Afterall, you said that in a previous email, "I interpret it as 'don't use timestmaps in a unidirectional way'." So are you now saying that RFC 1323 allows you to use timestamps in "undirectional way?" And think more about interoperability (you can ignore what I said about Solaris for this purpose). The fact is that all stacks nowadays send timestamp option is every segments once it is negotiated. And the fact that a TCP stack will never know how an app is going to use it. And ... There are a lot of issues to think about. > 3 & 4. > (a) I did answer your question. I never said it is always possible to figure > out whether it is possible to figure out whether timestamps are necessary at > the connection set up time (nor is it the problem I am trying to solve). All > I am trying to do is to timestamp (and echo) segments on a connection which > has timestamps negotiated on it only when it is necessary and useful, I said > nothing about figuruing out whenther they should be negotiated or not. So are you suggesting something that you don't even know how to make it work? > (b) I know that to do PAWS check, every segment needs to be timstamped. > However, to figure out whether PAWS check needs to be done or not, can be > implementation specific because there can be many reasons within the perview > of TCP or outside of it which could contribute to this. Note that, for a > connection to require PAWS check it has to (i) have a transfer rate of > greater than a threshold and (ii) have a life time greater than a threhold. > If it is possible to determine one of these is not going to be met, there is > no need to do PAWS on that connection. The maybe's were actually examples of > such instances: > > - A bandwidth limit is imposed on each connection {(i) fails} > - Connections are always secured with IPSEC, which has anti-replay > protection. > - A timestamp negotiated connection starts with the assumption that PAWS is > necessary at the peer and timestamps every segment to begin with. After it > has an estimate of the RTT, it figures out (i) will fail because the maximum > transfer rate is limited by the bandwidth-delay product. - The sending > application did a graceful close after submitting a buffer which is smaller > than what is takes to cover the sequence space. - A mail server admin knows > each client has a mailbox size maximum of 1 gigabytes and there is no > danger of wrap around when a mail client tries to download it. I am not trying to discourage you. But please think about how to write the above code and make it works every time reliably. Then test it and give us some results first. Write up a draft and we can have more fruitful discussions. > My point is that, this is really something that can't be put in a spec, but > chosen by many factors. Oops, without a spec, how are you going to tell people to employ it? > (c) Again, determining whehter timestamping every segment for RTTM is an > overkill or not should be an implemenation choice. Examples being: > > - The timer on the sender TCP has a granularity of 100 ms and the first 10 > RTT measurements are all below 50 seconds. > - The last 10 RTT measurements did not vary by more than 5%. > > 5. My suggestion was, if a sender TCP is able to figure this out, it can > selectively use timestamps. If the receiver also adheres to some well known > rule, it would save sending some extra bytes in either direction. The rule > is what I thought could be part of Eifel draft, as it was using timestamps > in a way other than RTTM and PAWS, and could be achieved wihtout > timestamping every segment. You might already have seen the following: > Sender-TCP would put a timestamp in a segment if: > * PAWS protection is necessary for the connection. > * An RTT measurement using timestamps is desired, and one such measurement > is in progress. We consider a measurement to be in progress if sender has > sent a timestamp after it started a measurement and it is not yet echoed > back. > * Retransmission of a segment upon timeout. > > Receiver-TCP would put a timestamp (or echo what it got) in an ack if: > * no more than 3 acks have been sent after any segment with a timestamp was > received. K. Poon. kcpoon@eng.sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 23:35:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01444 for ; Thu, 10 Jan 2002 23:35:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA06402 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 23:35:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05894; Thu, 10 Jan 2002 23:21:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05864 for ; Thu, 10 Jan 2002 23:21:10 -0500 (EST) Received: from starburst.demon.co.uk (starburst.demon.co.uk [194.222.114.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00964 for ; Thu, 10 Jan 2002 23:21:07 -0500 (EST) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id EAA08940; Fri, 11 Jan 2002 04:18:50 GMT From: Richard Wendland Message-Id: <200201110418.EAA08940@starburst.demon.co.uk> Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. To: kcpoon@eng.sun.com Date: Fri, 11 Jan 2002 04:18:49 +0000 (GMT) Cc: skaniyar@hotmail.com (sanjay kaniyar), tsvwg@ietf.org, Reiner.Ludwig@ericsson.com In-Reply-To: from "Kacheong Poon" at Jan 09, 2002 07:12:49 PM Reply-to: richard@codeburst.co.uk X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Transport Area Working Group X-BeenThere: tsvwg@ietf.org Content-Transfer-Encoding: 7bit > I don't know of > any implementation which does not send timestamp option in every > segment (besides, for example, RST) once it is negotiated at the > beginning. I do see some such behaviour, but it's not that common: timestamp on SYN-ACK but not subsequently. It's probably caused by devices like HTTP load-balancers (possibly old or mis-configured), I don't see enough of such behaviour to suggest it's due to a major TCP implementation. Try HTTP connections to: www.us.army.mil, www.fairchildsemi.com, www.goretex.com, www.westin.com, www.lclark.edu. I also see the opposite behaviour, no timestamp on SYN-ACK but timestamps on subsequent segments. To see this try HTTP to: www.arl.army.mil, www.bns.rutgers.edu, www.coolbean.com, www4.whirlpool.com. But I doubt it is worth specially accommodating this strange behaviour. NB I see this from a FreeBSD system with net.inet.tcp.rfc1323=1. > And for the sake of the RTTM and PAWS, I believe it > is safe to assume that if one side suddenly stops sending timestamp > option, there must be something wrong and RTTM and PAWS will not > be reliable. That seems a fair judgment to me at present. Richard -- Richard Wendland richard@codeburst.co.uk _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg From daemon@optimus.ietf.org Thu Jan 10 23:56:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01750 for ; Thu, 10 Jan 2002 23:56:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA06611 for tsvwg-archive@odin.ietf.org; Thu, 10 Jan 2002 23:56:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06466; Thu, 10 Jan 2002 23:39:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06435 for ; Thu, 10 Jan 2002 23:39:23 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01483 for ; Thu, 10 Jan 2002 23:39:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24420; Thu, 10 Jan 2002 21:39:23 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA23478; Thu, 10 Jan 2002 20:39:22 -0800 (PST) Date: Thu, 10 Jan 2002 20:38:41 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps. To: mallman@grc.nasa.gov Cc: Kacheong Poon , Reiner Ludwig

	1-866-733-8899
"VKI increased our web traffic by 550% which resulted in a 20% increase in revenues in less than six months." John Keith-King, Curator, Granville Island Museums. Would you like to see if you can achieve similar results? Call us at 1-866-733-8899 or fill out our online consultation and receive a FREE Search Engine Report (value $75.00)

THE BENEFITS
Your website will become highly visible Your traffic will grow exponentially Measurable and trackable results You will have an ongoing strategy that adapts as search engines change
THE ELEVATION
Strategy development Keyword Formulation Creation of keyword & description META tags Creation of keyword entry pages FTP file transfer to server Submission of web address (URL) to search engines Submission of web address (URL) to directory sites more info
THE PUSH - ongoing maintenance includes:
Optimization - HTML optimization to be search engine friendly Submission - Proper submission protocol for each individual engine Registration - Verification of successful submissions Monitoring - Evaluation of server file logs for search engine activity Positioning - Fine-tuning of submitted pages Maintenance - Continuous attendance to all the above actions Online consultation
Many Search Engines are moving to paid listings so ACT NOW! Contact us today to take advantage of our limited time offer. Please call us: 1-866-733-8899 or (604) 733-1474 - VKI Studios Inc.

If you do not wish to receive further mailings, please unsubscribe here.

사전 양해 없이 메일 드린 점 사과드립니다. 불필요한 메일이라면 바로 삭제하여 주시기 바랍니다.[소리첨부]

교통사고 보상상담

귀하의 품안에 원하는 애인을 쏘옥~~안겨드립니다!!

사전 양해 없이 메일 드린 점 사과드립니다.

불필요한 메일이라면 바로 삭제하여 주시기 바랍니다.[소리첨부]