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

[Jon Berger <[e-mail]>]

Reply below

Jon


-----Original Message-----
From: Qiaobing Xie [mailto:[e-mail]]
Sent: 26 February 2001 18:24
To: Jon Berger
Cc: Qiaobing Xie; SIGTRAN LIST (E-mail); [e-mail]
Subject: [Tsvwg] Re: I-D ACTION:draft-ietf-sigtran-usctp-01.txt


Jon,

See my comments below...

-Qiaobing

Jon Berger wrote:
> 
> 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.

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

> 
> 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."

Ok. will be added.

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

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.

[Jon] It is not immediately obvious to me why it is OK for IP fragmentation
to occur on unreliable messages but not on reliable messages.  If I better
understood the reasoning for the "MUST" in the RFC, this might help.
Randall?

> 
> Jon
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 20 February 2001 15:29
> To: IETF-Announce
> Cc: [e-mail]
> 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:
>         [e-mail].
> 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
[e-mail]
http://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tsvwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/tsvwg