Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt

From: [email-masked]
Date: Tue, 19 Oct 2004 07:50:30 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: Stream Control Transmission Protocol (SCTP) Implementer's Guide
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-tsvwg-sctpimpguide-12.txt
	Pages		: 96
	Date		: 2004-10-18
	
This document contains a compilation of all defects found up until
   the publishing of this document for the Stream Control Transmission
   Protocol (SCTP) RFC2960 [6].  These defects may be of an editorial or
   technical nature.  This document may be thought of as a companion
   document to be used in the implementation of SCTP to clarify errors
   in the original SCTP document.

   This document updates RFC2960 [6] and text within this document
   supersedes the text found in RFC2960 [6].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-sctpimpguide-12.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Oct 2004 14:23:03 -0400

All:

A point and a question..

  We probably need to think about last calling this and closing
  up the document. I think, based on the last inter-op, we have
  things pretty well complete as far as clearifications go..

The question..

One thing that has off and on nagged at me is the
following wording from RFC2960 ...

 From 8.4:

    The receiver of an OOTB packet MUST do the following:

    1) If the OOTB packet is to or from a non-unicast address, silently
       discard the packet.  Otherwise,
*******************************************************************
and From 11.2.4.1 Flooding

   -  not responding to unexpected packets sent to non-unicast
       addresses.

*******************************************************************

Now I realize that these strictures were put there to keep us
from setting up an association with a smurf like attack
i.e. src from X (the victim) and send an INIT
broadcast  255.255.255.255... or even multi-cast...

But I wonder, is the wording too strict here??

In the future if you are dealing with "Anycast" .. this is
NON-Unicast... and so you have to discard it.. but I could
see sometime down the road when we would WANT to respond
when sent to an ANYCAST address.... right now V6 limits that to
routers... some day anycast may go beyond routers...
And SCTP won't be able to use it due to the above
wording...

I could see...

From:IP-A ---INIT(IP-A) -->To:Anycast Address

<----To:IP-A ---INIT-ACK(IP-Z,AnyCast)from IP-Z
--From:IP-A-COOKIE-ECHO------->To IP-Z
  From:IP-A<------COOKIE-ACK+ASCONF(Delete Anycast)----From:IP-Z

Working just great...and making it so you could
establish an SCTP association with an ANYCAST address.... neat
idea.. but right now NOT allowed...

Soo.. should we just cross that bridge when we come
to it... or should we attempt to loosen up the wording
for anycast??

R

[email-masked] wrote:
> ------------------------------------------------------------------------
> 

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Oct 2004 13:30:04 -0600

Randall,

Loosen 1) to SHOULD.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Oct 2004 16:26:43 -0400

If no one else objects that seems to me
like a logical way to do it..

SHOULD throw it away

and SHOULD NOT be responding to.....

or something like that :-D

R

---

From: Peter Lei <[email-masked]>
Date: Fri, 22 Oct 2004 20:54:53 -0500

Yup, I'd like to see it as SHOULD silently discard the packet in
the first section you excerpted and SHOULD NOT respond to unexpected
packets in the second section.

regards,
--peter

Randall Stewart wrote:
>>>> [email-masked] with the word unsubscribe in the body 
>>>> of the message.  You can also visit 
>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
>>>> subscription settings.
>>>>
>>>>
>>>> http://www.ietf.org/shadow.html or 
>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>>>

---

From: Stephan Baucke <[email-masked]>
Date: Mon, 25 Oct 2004 10:55:02 +0200

Hi all,

I'd like to bring up another clarification which didn't make it into the
imp-guide in time (although I understand that the authors in principle
agree to include it). It is a clarification of Karn's algorithm which
sometimes results in wrong RTT samples being taken if not properly
implemented. AFAIK this problem is not clearly spelled out in RFC 2918
or other related IETF docs (please correct me if I'm wrong). I know of
at least one SCTP stack (and a certain simulator :) where this is
currently not correctly implemented. In essence, a cumulative ACK
resulting from a retransmission of an earlier packet can be mistaken for
an ACK for a timed packet. For illustration, consider the following example:

- Host A sends packets 1, 2 and 3 to host B, and choses packet 3 for an
RTT measurement
- Host B receives all packets correctly and sends ACK1, ACK2, and ACK3
- ACK2 and ACK3 are lost on the return path
- Eventually a timeout fires for packet 2, and A retransmits 2
- Upon receipt of 2, B sends a cumulative ACK3 (since it has received 2
and 3 before)
- Since packet 3 has never been retransmitted, even an SCTP
implementation strictly following 2960 could actually accept the ACK for
an RTT measurement, although it was sent in reply to the retransmission
of 2, resulting in a much too high RTT estimate. Since this tends to
happen in case of longer link interruptions, the error is often
amplified by subsequent timer back-offs.

The solution is to either cancel all pending RTT timings upon entering
the recovery phase (which is what e.g. BSD TCP does), or to cancel
timings for packets with TSNs higher than the retransmitted one. (note
that this issue is not a problem for TCP stacks using timestamps)

We propose to include the following clarification in the imp-guide:

Karn's algorithm: RTT measurements MUST only be made using a packet
with TSN r if no packet with TSN less than or equal to r is
retransmitted since r was first sent.

BR,
Stephan.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 25 Oct 2004 04:00:27 -0600

Stephan,

What damage might occur to the network otherwise that justifies using
MUST here?  What interoperability problems would occur?

Too high an RTT estimate doesn't look like a problem to anybody but
the sender, and appears to be more of a local performance consideration
to me...

It might warrant an implementation note, but a "MUST" level requirement
would need to be justified.

--brian

---

From: Stephan Baucke <[email-masked]>
Date: Mon, 25 Oct 2004 13:07:16 +0200

Brian,

after taking a peek into RFC 2119, I agree that the use of "MUST" seems
inappropriate, since there appears to be no danger of harming the
network or limiting interoperability. The clarification is meant to
point out a potential pitfall to implementers which can lead to
incorrect RTO calculations and bad performance.

BR,
Stephan.

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Mon, 25 Oct 2004 15:45:14 -0400 (EDT)

On Mon, 25 Oct 2004, Stephan Baucke wrote:

> implemented.

<snip>

> retransmitted since r was first sent.

Yes, that's my fault. I was supposed to put that change in.

Randall: Since I currently can't log into your machine, can you make the
change?

~armando

0--                                              --0
| Armando L. Caro Jr.  |  Protocol Engineering Lab |
| www.armandocaro.net  |    University of Delaware |
0--                                              --0

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Mon, 25 Oct 2004 15:46:47 -0400 (EDT)

> would need to be justified.

Well the wording that Stephan provided is just a modification of the
current wording in RFC2960's Section 6.3.1.C5, which already uses a "MUST"
level requirement.

~armando

0--                                              --0

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 25 Oct 2004 14:06:58 -0600

Armando,

> current wording in RFC2960's Section 6.3.1.C5, which already uses a "MUST"

Yes, not calculating the RTT correctly can damage the network.  (Just not
in the way Stephan details.)

--brian

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Oct 2004 16:06:09 -0400

> Randall: Since I currently can't log into your machine, can you make the

Yep... I will do so.. but I will change the MUST to a SHOULD
per the comments on the list so far..

R

-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

---

From: Stephan Baucke <[email-masked]>
Date: Tue, 26 Oct 2004 11:10:16 +0200

> current wording in RFC2960's Section 6.3.1.C5, which already uses a "MUST"

I'd say it depends on whether the new text will be put into the
imp-guide as a _replacement_ for the 2960 text, or as an addendum. In
the first case we will have to keep the MUST, since failure to comply
with the part of the rule already in 2960 may (as Brian correctly
pointed out) harm the network. If it is meant as an addendum containing
just the clarification about retransmitted packets with a smaller TSNs,
I guess a SHOULD would be appropriate.

BR,
Stephan.

---

From: Randall Stewart <[email-masked]>
Date: Tue, 26 Oct 2004 07:08:20 -0400

Stephan:

IMO this is something that should be ADDED to the
text as an implementation note:

aka:

IMPLEMENTATION NOTE: RTT measurements should only be made using a packet
with TSN r if no packet with TSN less than or equal to r is
retransmitted since r was first sent.

Does that sound agreeable to everyone... note the original
text in the MUST clause will remain..

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Oct 2004 05:34:30 -0600

Randall,

I agree that it is best as a supplemental implementation note
as worded.

--brian

---

From: Stephan Baucke <[email-masked]>
Date: Tue, 26 Oct 2004 16:31:15 +0200

Randall,

this is fine with me. As the problem description, I propose something
like the following:

The description of Karn's algorithm in RFC 2960 only states that
retransmitted packets must not be used for RTT measurements. But an RTT
measurement should also not be made if other packets with lower TSNs are
retransmitted while a packet is being timed. Otherwise an
acknowledgement resulting from such a retransmission can be mistaken for
the acknowledgement of the packet being timed (if it advances the
cumulative ACK point to the TSN of that packet). This results in an
incorrect RTT measurement.

Stephan.

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Tue, 26 Oct 2004 12:48:01 -0400 (EDT)

Yes, it looks good to me.

~armando

0--                                              --0
| Armando L. Caro, Jr. |  Protocol Engineering Lab |
| www.armandocaro.net  |    University of Delaware |
0--                                              --0

---

From: [email-masked]
Date: Mon, 25 Oct 2004 15:41:33 -0400 (EDT)

<snip>

~armando

0--                                              --0