Hi All, In <draft-stewart-tsvwg-sctpipv6-01.txt>, it refers to "IPv6 Scoped Address Architecture" which was mraked as work in proress. Is it complete and available now? If it is availabe, where can I find a copy of it? If it is not availabe, when will it be availabe? Thanks in advance. Simon
Simon: Using the ietf.org search for drafts page I find: http://search.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-04.txt R Simon.Zhuang <at> radisys.com wrote: > > Hi All, > > In <draft-stewart-tsvwg-sctpipv6-01.txt>, it refers to "IPv6 Scoped Address > Architecture" which was mraked as work in proress. Is it complete and > available now? If it is availabe, where can I find a copy of it? If it is > not availabe, when will it be availabe? > > Thanks in advance. > > Simon > > _______________________________________________ > tsvwg mailing list > tsvwg <at> ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- -- Randall R. Stewart randall <at> stewart.chicago.il.us 815-342-5222 (cell phone)(Continue reading)
Hi All, At the incoming SCTP bakeoff, what the test setups for IPv6 will look like? What are the test scenarios for IPv6? Will the followings be tested? IPv6 -> IPv6 associations (single homed? multi-homed?) dual stack ipv4 & ipv6 ? ip4->ipv6(mapped as a v4 addr) ipv6 tunneled over ipv4 ? Thanks in advance. Simon
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)
Implementors Guide
Author(s) : R. Stewart, L. Ong et al.
Filename : draft-ietf-tsvwg-sctpimpguide-06.txt
Pages : 54
Date : 01-Jul-02
This document contains a compilation of all defects found up until
the publishing of this document for the Stream Control Transmission
Protocol (SCTP) RFC2960 [3]. 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 [3] and text within this document
supersedes the text found in RFC2960 [3].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-06.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-sctpimpguide-06.txt".
(Continue reading)
A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SCTP Partial Reliability Extension Author(s) : R. Stewart, M. Ramalho et al. Filename : draft-stewart-tsvwg-prsctp-01.txt Pages : 25 Date : 01-Jul-02 This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC2960 [4] that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes (1) the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type (2) one example partially reliable service that can be provided to the upper layer via this mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-prsctp-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-stewart-tsvwg-prsctp-01.txt".(Continue reading)
Dear Simon, see my comments below. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN WN CC SE 7 e-Mail: Michael.Tuexen <at> icn.siemens.de > -----Original Message----- > From: Simon.Zhuang <at> radisys.com [mailto:Simon.Zhuang <at> radisys.com] > Sent: Wednesday, July 03, 2002 2:24 PM > To: tsvwg <at> ietf.org > Subject: [Tsvwg] What are the test setup & scenarios for IPv6 at the > incoming SCTP bakeoff > > At the bakeoffs we use always (almost) the same setup. > Hi All, > > At the incoming SCTP bakeoff, what the test setups for IPv6 > will look like? > What are the test scenarios for IPv6? Will the followings be tested? > IPv6 -> IPv6 associations (single homed? multi-homed?) You normally get two ethernet connections. Each gives you access to an IPv4 net and an IPv6 net. Routers make sure that everyone can be reached. So if you have a IPv6 only implementation you can use it, if you have a IPv4 only inplementation you can use it, if you have a(Continue reading)
A recent paper at ICC 2002 ("Improving TCP Performance after a Long Channel
Outage" by Murakami, Wu, and Inoue) describes some pathological behavior
that might arise due to strict observance of draft-allman-tcp-sack-11.txt.
The problem is basically as follows:
- consider a TCP, with a somewhat large usable window, that traverses a path
that becomes blocked for a duration of time that it is able to "swallow"
roughly a window's worth of data and ACKs.
- this TCP will time out eventually (setting cwnd to 1 segment) and resend
its oldest unacked segment. At some point, the blockage clears and a
retransmission and ACK thereof make it through the channel.
- this first ACK received will have no SACK blocks since all of the data off
the top of the window was lost. According to the algorithm, HighACK will
grow by one segment, so pipe will decrement a corresponding amount. But
pipe will still be a large (multiple segments), and greater than cwnd. Note
that the internet-draft does not say anything about touching any of the
variables determining "LeftNetwork()" when a timeout occurs.
- at this point, correct behavior is somewhat ambiguous (underspecified).
Murakami et al., who cite draft-allman-tcp-sack-07.txt, describe a TCP
sender that waits again for timeouts for each subsequent retransmission
(ever increasing the backoff), resulting in recoveries that can last for
tens of minutes. If instead the TCP sender always permits at least one
transmission upon receipt of an ACK, it may instead send the next
retransmission in response to this ACK, without waiting for a timeout. But
the bottom line is that it seems that at most one segment can be recovered
per RTT if pipe control is used and pipe > cwnd.
(Continue reading)
Henderson, Thomas R spake unto us the following wisdom:
> A recent paper at ICC 2002 ("Improving TCP Performance after a Long Channel
> Outage" by Murakami, Wu, and Inoue) describes some pathological behavior
> that might arise due to strict observance of draft-allman-tcp-sack-11.txt.
> The problem is basically as follows:
>
> - consider a TCP, with a somewhat large usable window, that traverses a path
> that becomes blocked for a duration of time that it is able to "swallow"
> roughly a window's worth of data and ACKs.
It appears to me that by this you mean that the packets are actually
*lost*, and not just delayed for a ridiculous period of time.
> - this TCP will time out eventually (setting cwnd to 1 segment) and resend
> its oldest unacked segment. At some point, the blockage clears and a
> retransmission and ACK thereof make it through the channel.
OK.
> - this first ACK received will have no SACK blocks since all of the data off
> the top of the window was lost. According to the algorithm, HighACK will
> grow by one segment, so pipe will decrement a corresponding amount. But
> pipe will still be a large (multiple segments), and greater than cwnd. Note
> that the internet-draft does not say anything about touching any of the
> variables determining "LeftNetwork()" when a timeout occurs.
Correct, according to my reading.
> - at this point, correct behavior is somewhat ambiguous (underspecified).
> Murakami et al., who cite draft-allman-tcp-sack-07.txt, describe a TCP
(Continue reading)
> It appears to me that by this you mean that the packets are actually > *lost*, and not just delayed for a ridiculous period of time. > Yes. > > - at this point, correct behavior is somewhat ambiguous > (underspecified). > > Murakami et al., who cite draft-allman-tcp-sack-07.txt, > describe a TCP > > sender that waits again for timeouts for each subsequent > retransmission > > (ever increasing the backoff), resulting in recoveries that > can last for > > tens of minutes. If instead the TCP sender always permits > at least one > > transmission upon receipt of an ACK, it may instead send the next > > retransmission in response to this ACK, without waiting for > a timeout. But > > the bottom line is that it seems that at most one segment > can be recovered > > per RTT if pipe control is used and pipe > cwnd. > > This appears to be incorrect. At this point the TCP sender is not > being governed by draft-allman-tcp-sack-11, but by traditional slow > start with the added condition that "Update () MAY continue to be used > appropriately upon receipt of ACKs". Because of this, the values of > LeftNetwork (), HighData, etc. are not relevant. > > There may in fact be some issues if there is a second loss (after the(Continue reading)
Dear Simon, dear all, as Michael already explained, the setups will be similar to the last interop tests. That meaning: we use FreeBSD boxes as gateway routers which support IPv4 and IPv6 and you get two ethernet drops in two IPv4 class C subnets, respectively two IPv6 global and site-local /64 prefixes, from which your IPv6 host will auto-configure global, site-local and link-local IPv6 addresses. > > What are the test scenarios for IPv6? I am currently planning the scenarios as well as the setup for the interop. In about 2 weeks time I will notify all registered participants, and mail them a detailed plan for address configuration and network and such. Testing will be based on the document http://search.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpscore-00.txt and I will try to outline a detailed set of scenarios for the 5 days of the interop, in two weeks time. > > Will the followings be tested? > > - IPv6 -> IPv6 associations (single homed? multi-homed?) > > - dual stack ipv4 & ipv6 Yes. As you wish. > > ip4->ipv6(mapped as a v4 addr) Have not really looked into this way of operation. But I am sure that SCTP implementations will not support it !(Continue reading)
RSS Feed23 | |
|---|---|
50 | |
156 | |
58 | |
23 | |
28 | |
65 | |
72 | |
12 | |
29 | |
70 | |
50 | |
24 | |
51 | |
72 | |
14 | |
17 | |
30 | |
24 | |
23 | |
18 | |
45 | |
37 | |
31 | |
19 | |
11 | |
139 | |
30 | |
136 | |
69 | |
60 | |
57 | |
48 | |
81 | |
28 | |
19 | |
33 | |
13 | |
72 | |
74 | |
65 | |
49 | |
94 | |
91 | |
30 | |
34 | |
51 | |
21 | |
162 | |
17 | |
44 | |
51 | |
20 | |
11 | |
125 | |
102 | |
89 | |
21 | |
64 | |
12 | |
82 | |
97 | |
50 | |
56 | |
78 | |
30 | |
29 | |
69 | |
60 | |
41 | |
143 | |
91 | |
56 | |
121 | |
118 | |
34 | |
80 | |
78 | |
142 | |
128 | |
79 | |
37 | |
90 | |
180 | |
75 | |
128 | |
170 | |
66 | |
67 | |
67 | |
163 | |
101 | |
242 | |
110 | |
21 | |
18 | |
28 | |
28 | |
54 | |
38 | |
26 | |
36 | |
82 | |
78 | |
29 | |
31 | |
28 | |
15 | |
5 | |
16 | |
109 | |
48 | |
22 | |
43 | |
49 | |
41 | |
14 | |
83 | |
152 | |
44 | |
93 | |
111 | |
133 | |
115 | |
44 | |
181 | |
61 | |
148 | |
77 | |
91 | |
92 | |
88 | |
209 | |
198 |
