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

From: Jon Berger <[email-masked]>
Date: Tue, 27 Feb 2001 11:47:54 -0000

Reply below

Jon

-----Original Message-----
From: Qiaobing Xie [mailto:[email-masked]]
Sent: 26 February 2001 18:24
To: Jon Berger
Cc: Qiaobing Xie; SIGTRAN LIST (E-mail); [email-masked]
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: [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

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 27 Feb 2001 06:37:23 -0600

> understood the reasoning for the "MUST" in the RFC, this might help.

Well, I will attempt to answer this..

When a reliable transport such as TCP or SCTP sends
information it is always optimal for the IP layer
NOT to do fragmentation. This is logical if one
thinks about it, since if you do send 4000 bytes
IPv4 is going to fragment it into somewhere between
3-9 pieces (depending on the P-MTU of course). Now
lets say its 8 for fun... if we transport 7 of the
pieces and the 8th drops... SCTP/TCP will end up
retransmitting the 4000 byte packet again. So you
waste bandwidth by transporting the same good 7th
and then the 8th... 

There have been studies done (you will have to look
them up if you are interested.. start with the
P-MTU RFC's ..) that show how bad this is and it
is something we need to avoid...

Now for a u-sctp packet... you are not really going
to retransmit (at least in theory) any of the packets.
So if one lets IP fragment it should be ok.

Now I do have some concerns thinking about it:

A) In IPv6 SCTP will STILL need to do fragmentation
   through IPv6 fragmentation headers. IPv6 does
   not support the IP_DF type bit and it becomes
   the transport layer responsibility to use the
   fragmentation header.... 

B) The current definition of the draft is a N retransmit
   where N is a number starting at 0. If you set N to 
   anything but 0 then the above retransmitting becomes
   a problem..

Maybe we DO want to go in and fix this in the next pass since
we ARE allowing a N retransmit...

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)