bhanu | 2 Jun 2005 16:16
Picon

ABORT processing

Hai all..

The RFC-2960 section: 3.3.7 says:
    If an endpoint receives an ABORT with a format error or for an
   association that doesn't exist, it MUST silently discard it.

Here the "format error" indicates what..?

When a ABORT is received with some Error Causes, if one of the error causes in it
is invalid (i.e cause length may be wrong or the error content may be wrong)
what action need to be taken...?
Should we accept the ABORT by neglecting the error cause in it   or   the whole ABORT
chunk need to be dropped..?

Please clarify.

Regards
Bhanu.
_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Brian F. G. Bidulock | 2 Jun 2005 17:46
Favicon

Re: ABORT processing

bhanu,

 If an endpoint receives an ABORT with a format error or for an
 association that doesn't exist, it MUST silently discard it.

--brian

On Thu, 02 Jun 2005, bhanu wrote:

> 
>    Hai all..
>    The RFC-2960 section: 3.3.7 says:
>        If an endpoint receives an ABORT with a format error or for an
>       association that doesn't exist, it MUST silently discard it.
>    Here the "format error" indicates what..?
>    When  a  ABORT is received with some Error Causes, if one of the error
>    causes in it
>    is  invalid (i.e cause length may be wrong or the error content may be
>    wrong)
>    what action need to be taken...?
>    Should  we  accept  the ABORT by neglecting the error cause in it   or
>    the whole ABORT
>    chunk need to be dropped..?
>    Please clarify.
>    Regards
>    Bhanu.

> _______________________________________________
> tsvwg mailing list
> tsvwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg

--

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock <at> openss7.org    ¦ 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 ¦
bhanu | 2 Jun 2005 18:15
Picon

Re: ABORT processing


Hi

In my case the format of ABORT is correct (i.e:Type and chunk length is correct),
but the error cause in it is invalid..!! (e.g: cause length is invalid)

As the receiver will not do anything with the error cause built in an ABORT..!!
is it mandatory to drop ABORT..?

Please clarify
Bhanuprakash


I do not think the receiver will do anything  with it,

Brian F. G. Bidulock wrote:
bhanu, If an endpoint receives an ABORT with a format error or for an association that doesn't exist, it MUST silently discard it. --brian On Thu, 02 Jun 2005, bhanu wrote:
Hai all.. The RFC-2960 section: 3.3.7 says: If an endpoint receives an ABORT with a format error or for an association that doesn't exist, it MUST silently discard it. Here the "format error" indicates what..? When a ABORT is received with some Error Causes, if one of the error causes in it is invalid (i.e cause length may be wrong or the error content may be wrong) what action need to be taken...? Should we accept the ABORT by neglecting the error cause in it or the whole ABORT chunk need to be dropped..? Please clarify. Regards Bhanu.
_______________________________________________ tsvwg mailing list tsvwg <at> ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Michael Tuexen | 2 Jun 2005 18:24
Picon

Re: ABORT processing

Hi Bhanuprakash,

the important point here is that you do not send an ABORT!

Assuming that you got an ABORT for an existing association and
you have the number of bytes in the packet which is indicated
by the chunk length, it is up to you to delete the association
or not. But do not send anything.

Best regards
Michael

On Jun 2, 2005, at 18:15 Uhr, bhanu wrote:

>
>  Hi
>
>  In my case the format of ABORT is correct (i.e:Type and chunk length 
> is correct),
>  but the error cause in it is invalid..!! (e.g: cause length is 
> invalid)
>
>  As the receiver will not do anything with the error cause built in an 
> ABORT..!!
>  is it mandatory to drop ABORT..?
>
>  Please clarify
>  Bhanuprakash
>
>
>  I do not think the receiver will do anything  with it,
>
>  Brian F. G. Bidulock wrote:
>> bhanu,
>>
>>  If an endpoint receives an ABORT with a format error or for an
>>  association that doesn't exist, it MUST silently discard it.
>>
>> --brian
>>
>> On Thu, 02 Jun 2005, bhanu wrote:
>>
>>
>>>    Hai all..
>>>    The RFC-2960 section: 3.3.7 says:
>>>        If an endpoint receives an ABORT with a format error or for an
>>>       association that doesn't exist, it MUST silently discard it.
>>>    Here the "format error" indicates what..?
>>>    When  a  ABORT is received with some Error Causes, if one of the 
>>> error
>>>    causes in it
>>>    is  invalid (i.e cause length may be wrong or the error content 
>>> may be
>>>    wrong)
>>>    what action need to be taken...?
>>>    Should  we  accept  the ABORT by neglecting the error cause in it 
>>>   or
>>>    the whole ABORT
>>>    chunk need to be dropped..?
>>>    Please clarify.
>>>    Regards
>>>    Bhanu.
>>>
>>
>>> _______________________________________________
>>> tsvwg mailing list
>>> tsvwg <at> ietf.org
>>> https://www1.ietf.org/mailman/listinfo/tsvwg
>>>
>>
>>
>
> _______________________________________________
> tsvwg mailing list
> tsvwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg
Michael Tuexen | 2 Jun 2005 18:21
Picon

Re: ABORT processing

Hi Bhanuprakash,

the important point here is that you do not send an ABORT!

Assuming that you got an ABORT for an existing association and
you have the number of bytes in the packet which is indicated
by the chunk length, it is up to you to delete the association
or. But do not send anything.

Best regards
Michael

On Jun 2, 2005, at 18:15 Uhr, bhanu wrote:

>
>  Hi
>
>  In my case the format of ABORT is correct (i.e:Type and chunk length 
> is correct),
>  but the error cause in it is invalid..!! (e.g: cause length is 
> invalid)
>
>  As the receiver will not do anything with the error cause built in an 
> ABORT..!!
>  is it mandatory to drop ABORT..?
>
>  Please clarify
>  Bhanuprakash
>
>
>  I do not think the receiver will do anything  with it,
>
>  Brian F. G. Bidulock wrote:
>> bhanu,
>>
>>  If an endpoint receives an ABORT with a format error or for an
>>  association that doesn't exist, it MUST silently discard it.
>>
>> --brian
>>
>> On Thu, 02 Jun 2005, bhanu wrote:
>>
>>
>>>    Hai all..
>>>    The RFC-2960 section: 3.3.7 says:
>>>        If an endpoint receives an ABORT with a format error or for an
>>>       association that doesn't exist, it MUST silently discard it.
>>>    Here the "format error" indicates what..?
>>>    When  a  ABORT is received with some Error Causes, if one of the 
>>> error
>>>    causes in it
>>>    is  invalid (i.e cause length may be wrong or the error content 
>>> may be
>>>    wrong)
>>>    what action need to be taken...?
>>>    Should  we  accept  the ABORT by neglecting the error cause in it 
>>>   or
>>>    the whole ABORT
>>>    chunk need to be dropped..?
>>>    Please clarify.
>>>    Regards
>>>    Bhanu.
>>>
>>
>>> _______________________________________________
>>> tsvwg mailing list
>>> tsvwg <at> ietf.org
>>> https://www1.ietf.org/mailman/listinfo/tsvwg
>>>
>>
>>
>
> _______________________________________________
> tsvwg mailing list
> tsvwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg
Internet-Drafts | 3 Jun 2005 21:58
Picon
Favicon

I-D ACTION:draft-ietf-tsvwg-quickstart-00.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		: Quick-Start for TCP and IP
	Author(s)	: S. Floyd, et al.
	Filename	: draft-ietf-tsvwg-quickstart-00.txt,.ps
	Pages		: 65
	Date		: 2005-6-3
	
This document specifies an optional Quick-Start mechanism for
    transport protocols, in cooperation with routers, to determine an
    allowed sending rate at the start and at times in the middle of a
    data transfer.  While Quick-Start is designed to be used by a range
    of transport protocols, in this document we describe its use with
    TCP.  By using Quick-Start, a TCP host, say, host A, would indicate
    its desired sending rate in bytes per second, using a Quick Start
    Request option in the IP header of a TCP packet.  Each router along
    the path could, in turn, either approve the requested rate, reduce
    the requested rate, or indicate that the Quick-Start request is not
    approved.  If the Quick-Start request is not approved, then the
    sender would use the default congestion control mechanisms.  The
    Quick-Start mechanism can determine if there are routers along the
    path that do not understand the Quick-Start Request option, or have
    not agreed to the Quick-Start rate request.  TCP host B communicates
    the final rate request to TCP host A in a transport-level Quick-
    Start Response in an answering TCP packet.  Quick-Start is designed
    to allow connections to use higher sending rates when there is
    significant unused bandwidth along the path, and all of the routers
    along the path support the Quick-Start Request.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-quickstart-00.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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-quickstart-00.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.
Attachment: message/external-body, 139 bytes
Attachment (draft-ietf-tsvwg-quickstart-00.txt): message/external-body, 68 bytes
_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Paul D. Amer | 7 Jun 2005 18:59
Picon
Favicon

Corrected FTP over SCTP results

In the 23rd IEEE International Performance, Computing, and
Communications Conf (IPCCC 2004), Phoenix, 4/04,
Sourabh Ladha and I published the paper
``Improving multiple file transfers using SCTP multistreaming.''

Unbeknownst to us, in our experiments the SCTP end-points incorrectly
used Netbed's error-free, no-delay control connection for retransmissions
thereby biasing the results in favor of SCTP. (Multihoming was
taking place implicitly.)

We have corrected this error, and re-run the entire set of experiments.
The corrected results still show that SCTP with multistreaming and the
use of command pipelining can provide significant reductions in
the time to transfer multiple files, although less significant than
previously published.

The corrected results are available at
http://www.cis.udel.edu/~amer/PEL/poc/pdf/IPCCC2004CORRECTED-FTP-over-SCTP-Natarajan-6-6-2005.pdf

We sincerely regret our oversight.

Paul D. Amer
Sourabh Ladha
Internet-Drafts | 7 Jun 2005 22:05
Picon
Favicon

I-D ACTION:draft-ietf-tsvwg-addip-sctp-12.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) Dynamic 
			  Address Reconfiguration
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-tsvwg-addip-sctp-12.txt
	Pages		: 37
	Date		: 2005-6-7
	
This document describes extensions to the Stream Control Transmission
   Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
   address information on an existing association.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-addip-sctp-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:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-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.
Attachment: message/external-body, 139 bytes
Attachment (draft-ietf-tsvwg-addip-sctp-12.txt): message/external-body, 68 bytes
_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
Internet-Drafts | 7 Jun 2005 22:05
Picon
Favicon

I-D ACTION:draft-ietf-tsvwg-sctpimpguide-14.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) 
			  Implementer's Guide
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-tsvwg-sctpimpguide-14.txt
	Pages		: 105
	Date		: 2005-6-7
	
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-14.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-sctpimpguide-14.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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-14.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.
Attachment: message/external-body, 141 bytes
Attachment (draft-ietf-tsvwg-sctpimpguide-14.txt): message/external-body, 68 bytes
_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
Sally Floyd | 9 Jun 2005 17:16

Quick-Start: the ISN for retransmitted SYN packets?

One technical question for the Quick-Start draft is the
Initial Sequence Number (ISN)  to use for a retransmitted SYN packet.
The current draft says the following, in Section 4.6.3:

    While RFC 1122 and 2988 recommend that the sender should set the
    initial RTO to three seconds, many TCP implementations set the
    initial RTO to one second.  For a TCP SYN packet sent with a Quick-
    Start request, we RECOMMEND an RTO of one second, so that the sender
    can retransmit the SYN packet reasonably promptly if the original
    TCP SYN packet is dropped by a middlebox in the network.

    In the case of a retransmission, in addition to resending the SYN or
    SYN/ACK packet without the Quick-Start Request, the TCP sender
    SHOULD use an RTO of three seconds and a different Initial Sequence
    Number.  Using this scheme the TCP sender MUST keep track of when
    each of the SYN (or SYN/ACKs) was transmitted.  In this way, an
    acknowledgement for the retransmitted SYN or SYN/ACK packet can be
    matched with the SYN or SYN/ACK being acknowledged, and the
    transmission time of the SYN (or SYN/ACK) being acknowledged can be
    used for an RTT measurement to seed the RTO.  If only the
    retransmitted SYN or SYN/ACK is acknowledged, the TCP sender can
    reasonably assume that the earlier SYN or SYN/ACK with the Quick-
    Start option was dropped by the network because of the option and
    not because of congestion.  In this case, the TCP sender can refrain
    from performing TCP's standard congestion control state changes.

Here is the scenario:

    Sender                                        Receiver
    ------                                        --------
    SYN (or SYN/ACK) packet --->
               SYN Packet Dropped by Middlebox
    One second RTO
    Retransmitted SYN packet (new ISN?) --->
                                       <--- Acknowledgement  

The question is whether there are any TCP implementations out there
that would react badly if the retransmitted SYN packet uses an
different ISN that the original SYN packet.  We are hoping to 
run some tests to find out, but we thought that someone might
already know.  If it is not feasible to use a different ISN for a
retransmitted SYN packet, then we would use the same ISN, and the
consequences would simply be that the sender would be less likely
to get a valid RTT measurement from the SYN exchange.

In particular, if the first SYN still contained the Quick-Start
Request when it arrived at the receiver, and the receiver responded
to the sender with a Quick-Start response, then the sender would
know that this feedback was to the first SYN packet rather than to
the retransmitted SYN packet, and the sender would have a valid RTT
measurement (and the possibility of using Quick-Start).  However,
in all other cases, the sender would not be able to determing whether
feedback to the SYN packet was for the first SYN packet or for the
retransmitted SYN packet, and would not be able to make a valid RTT
measurement.

E.g., consider the case when some router deleted the IP Quick-Start
Option from the first SYN packet, the ACK from the receiver did not
arrive within one second, and the sender retransmitted the SYN
packet with the same ISN (but without the Quick-Start Option).  The
sender would not be able to determine whether the ACK was in response
to the first or second SYN, and would not be able to make a valid
RTT measurement.

Feedback?

Does anyone know how TCP implementations respond to the retransmission
of a SYN packet with a different ISN?

- Sally 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-quickstart-00.txt

Gmane