Subject: [Tsvwg] RE: I-D ACTION:draft-ietf-sigtran-usctp-01.txt

From: Jon Berger <[email-masked]>
Date: Thu, 22 Feb 2001 10:50:44 -0000

Qiaobing,

A few more comments on this latest draft.

1) Section 3.2.2
The description of the B and E bits indicates that fragmentation is not
allowed in the P-DATA chunk, but the text in section 5 explicitly states
that fragmentation is allowed.  I think you need to update this section with
the text from the RFC.

2) Section 3.2.2
One thing that isn't explicitly mentioned (although is implied) is when to
calculate the checksum on padding bytes.  Maybe the addition of the
following sentence at the end of the Checksum Coverage section would help?
"Padding at the end of the P-DATA chunk MUST NOT be considered when
calculating the Adler-32 checksum."

3) Section 4.2 
The second paragraph states that unreliable data must not be fragmented but
transmitted in one go no matter what the size.  Section 6.9 of the RFC says
that, if fragmentation is supported, messages larger than the MTU must
either be fragmented or not sent at all.  I'm not aware of the reasoning for
this requirement in the RFC but I think we should be consistent.

Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 20 February 2001 15:29
To: IETF-Announce
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-sigtran-usctp-01.txt

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

	Title		: SCTP Unreliable Data Mode Extension
	Author(s)	: Q. Xie, R. Stewart, C. Sharp, I. Rytina
	Filename	: draft-ietf-sigtran-usctp-01.txt
	Pages		: 14
	Date		: 19-Feb-01
	
This document describes an extension to the Stream Control
Transmission Protocol (SCTP) [RFC2960] to provide unreliable data
transfer services. The benefits of this extension includes unified
congestion control over reliable and unreliable data streams, single
association for multi-content data services, link level
fault tolerance for unreliable data transfer, unreliable data stream
multiplexing, etc. 

The unreliable data transfer service will also support partial payload
checksum in order to facilitate bit-error tolerance media
applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-usctp-01.txt

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-sigtran-usctp-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-usctp-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
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 26 Feb 2001 12:24:26 -0600

Jon,

See my comments below...

-Qiaobing

> that fragmentation is allowed.  I think you need to update this section with

Yeah, this is a little messy in the document. P-DATA can be either
reliable or unreliable depends on which steam it is sent to.
Fragmentation is only prohibited on *unreliable P-DATA* (ie., when it is
sent to an unreliable stream) but not prohibited if it is sent to a
reliable stream. I will clean this up in the next revision (we are in
fact proposing two different extensions in this one draft).

> calculating the Adler-32 checksum."

Ok. will be added.

> this requirement in the RFC but I think we should be consistent.

I don't see any inconsistency here. Section 6.9 of RFC2960 is talking
about reliable messages, while Section 4.2 of this document deals with
__unreliable__ messages.