Simon.Zhuang | 1 Jul 15:59 2002

IPv6 Scoped Address Architecture

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
Randall Stewart | 1 Jul 21:45 2002
Picon
Picon

Re: IPv6 Scoped Address Architecture

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)

Simon.Zhuang | 3 Jul 14:24 2002

What are the test setup & scenarios for IPv6 at the incoming SCTP bakeoff

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
Internet-Drafts | 2 Jul 12:35 2002
Picon

I-D ACTION:draft-ietf-tsvwg-sctpimpguide-06.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		: 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)

Internet-Drafts | 2 Jul 12:33 2002
Picon

I-D ACTION:draft-stewart-tsvwg-prsctp-01.txt

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)

Tuexen Michael | 3 Jul 16:13 2002
Picon

RE: What are the test setup & scenarios for IPv6 at the i ncoming SCTP bakeoff

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)

Henderson, Thomas R | 9 Jul 17:28 2002
Picon

problem with draft-allman-tcp-sack-11.txt

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)

Ethan Blanton | 9 Jul 18:07 2002

Re: problem with draft-allman-tcp-sack-11.txt

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)

Henderson, Thomas R | 9 Jul 18:47 2002
Picon

RE: problem with draft-allman-tcp-sack-11.txt

> 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)

Andreas Jungmaier | 10 Jul 17:01 2002
Picon

Re: What are the test setup & scenarios for IPv6 at the incoming SCTP bakeoff


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)


Gmane