Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt

From: Nagesh shamnur <[email-masked]>
Date: Tue, 7 Apr 2015 14:00:41 +0000

Hi Group,
	While going through the draft, draft-ietf-tsvwg-sctp-ndata-03 I got the following doubt and hence this mail.

	Why MID is required even for the unordered data, by the nature of the unordered data, it can come in any order, and hence SSN/MID is not required. 

	 Is it that, it Can MID be used only in case of unordered fragment data and not for all the unordered data? But again, as per the draft, the sender MUST NOT have more than one un-ordered fragmented message being produced in any one stream, so in that case also, MID wouldn't be required. 

	Is there something which I am missing here?

Regards,
Nagesh.

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 10 March 2015 05:55
To: [email-masked]
Cc: [email-masked]
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.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 Schedulers and User Message Interleaving for the Stream Control Transmission Protocol
        Authors         : Randall R. Stewart
                          Michael Tuexen
                          Salvatore Loreto
                          Robin Seggelmann
	Filename        : draft-ietf-tsvwg-sctp-ndata-03.txt
	Pages           : 14
	Date            : 2015-03-09

Abstract:
   The Stream Control Transmission Protocol (SCTP) is a message oriented
   transport protocol supporting arbitrary large user messages.
   However, the sender can not interleave different user messages which
   causes head of line blocking at the sender side.  To overcome this
   limitation, this document adds a new data chunk to SCTP.

   Whenever an SCTP sender is allowed to send a user data, it can
   possibly choose from multiple outgoing SCTP streams.  Multiple ways
   for this selection, called stream schedulers, are defined.  Some of
   them don't require the support of user message interleaving, some do.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-03

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 7 Apr 2015 17:01:33 +0200

> On 07 Apr 2015, at 16:00, Nagesh shamnur <[email-masked]> wrote:
> 
> Hi Group,
If you have multiple fragments belonging to the same unordered message, you need an identifier for
that message. The MID is the same for all fragments of the same user message.
> 	 Is it that, it Can MID be used only in case of unordered fragment data and not for all the unordered data? But again, as per the draft, the sender MUST NOT have more than one un-ordered fragmente…
That statement needs to be clarified. It means that the sender will not interleave two unordered fragmented
messages when breaking them into DATA chunks. However, this does not mean that there can't be multiple
unordered fragmented messages on the same stream in flight.

Best regards
Michael

---

From: Nagesh shamnur <[email-masked]>
Date: Wed, 8 Apr 2015 05:52:01 +0000

Hi Michael,
	Thanks for the answer. Please find my reply in-line.

Regards,
Nagesh.

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: 07 April 2015 23:02
To: Nagesh shamnur
Cc: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt

> 	Why MID is required even for the unordered data, by the nature of the unordered data, it can come in any order, and hence SSN/MID is not required. 
If you have multiple fragments belonging to the same unordered message, you need an identifier for that message. The MID is the same for all fragments of the same user message.
> 	 Is it that, it Can MID be used only in case of unordered fragment data and not for all the unordered data? But again, as per the draft, the sender MUST NOT have more than one un-ordered fragmente…
That statement needs to be clarified. It means that the sender will not interleave two unordered fragmented messages when breaking them into DATA chunks. However, this does not mean that there can't be multiple unordered fragmented messages on the same stream in flight.
In spite of that, for unordered messages, MID is not required. In case of DATA message (earlier), for both fragmented and un-fragmented unordered messages, SSN was not required, and the receiver was able to reassemble with the help of TSN, Begin and End Bits. Now in case of I-DATA chunk, since more than one un-ordered fragmented message cannot be interleaved, the same logic as DATA chunk (TSN, B & E flags) can be used to reassemble. So, the MID can be altogether removed for un-ordered messages in general.
 
Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 8 Apr 2015 21:01:53 +0200

> On 08 Apr 2015, at 07:52, Nagesh shamnur <[email-masked]> wrote:
> 
> Hi Michael,
Hi Nagesh,

the point is that we want to allow to interleave messages from different streams. RFC 4960 does not
allow message interleaving at all. We don't see a need for interleaving multiple messages from the
same stream. This doesn't make sense for ordered messages and we don't think it is of much use
for unordered ones.
> In spite of that, for unordered messages, MID is not required. In case of DATA message (earlier), for both fragmented and un-fragmented unordered messages, SSN was not required, and the receiver wa…
But then you can't interleave messages from multiple streams. You would require consecutive TSN assignments.

Assume the sender sends two three unordered messages resulting in the following TSN assignments.

I-DATA[flags=BU; TSN=0;SID=0;MID=0;FSN=0]
I-DATA[flags=BEU;TSN=1;SID=1;MID=0;FSN=0]
I-DATA[flags=BEU;TSN=2;SID=1;MID=1;FSN=0]
I-DATA[flags=EU; TSN=3;SID=0;MID=0;FSN=1]

Now assume that only the first and last message are received. With the MID, the receiver
knows that it has a complete message an can deliver it right away. Without the MID, the
receiver can't deliver the message, since the sender might have sent:

I-DATA[flags=BU; TSN=0;SID=0;MID=0;FSN=0]
I-DATA[flags=EU; TSN=1;SID=0;MID=0;FSN=0]
I-DATA[flags=BU; TSN=2;SID=0;MID=1;FSN=0]
I-DATA[flags=EU; TSN=3;SID=0;MID=1;FSN=1]

and reassembling the first and last doesn't make sense.

Best regards
Michael

---

From: Nagesh shamnur <[email-masked]>
Date: Thu, 9 Apr 2015 07:09:11 +0000

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: 09 April 2015 03:02
To: Nagesh shamnur
Cc: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt

Hi Nagesh,

the point is that we want to allow to interleave messages from different streams. RFC 4960 does not allow message interleaving at all. We don't see a need for interleaving multiple messages from the same stream. This doesn't make sense for ordered messages and we don't think it is of much use for unordered ones.

I-DATA[flags=BU; TSN=0;SID=0;MID=0;FSN=0] I-DATA[flags=BEU;TSN=1;SID=1;MID=0;FSN=0]
I-DATA[flags=BEU;TSN=2;SID=1;MID=1;FSN=0]
I-DATA[flags=EU; TSN=3;SID=0;MID=0;FSN=1]

Now assume that only the first and last message are received. With the MID, the receiver knows that it has a complete message an can deliver it right away. Without the MID, the receiver can't deliver the message, since the sender might have sent:

I-DATA[flags=BU; TSN=0;SID=0;MID=0;FSN=0] I-DATA[flags=EU; TSN=1;SID=0;MID=0;FSN=0] I-DATA[flags=BU; TSN=2;SID=0;MID=1;FSN=0] I-DATA[flags=EU; TSN=3;SID=0;MID=1;FSN=1]

and reassembling the first and last doesn't make sense.
[Nagesh]: Thanks a lot for explaining things to me, now it makes more sense. In that case, is it possible to make the MID mandatory only for unordered fragmented and unordered non-fragmented case, it can be ignored by both sender and receiver. Since, the true nature of the unordered message can be retained. Since having the MID for the unordered non-fragmented message is actually dummy and both sender and receiver wouldn't be able to take any actions on that.
Best regards
Michael
>>  The Stream Control Transmission Protocol (SCTP) is a message 
>> oriented  transport protocol supporting arbitrary large user messages.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 9 Apr 2015 10:53:13 +0200

> On 09 Apr 2015, at 09:09, Nagesh shamnur <[email-masked]> wrote:
> 
> 
I agree, that for un-ordered, un-fragmented user messages the MID is not important for the receiver.
However, I don’t want to make the I-DATA chunk header a variable size header. So the field is always
there. From my perspective, it is simpler to require the sender to fill in the field always by
incrementing it compared to state that it needs to be incremented always, except for un-ordered and
un-fragmented user messages. The receiver will just not make use of it.
I don’t see any benefit it setting the field to some special value (like 0) for un-ordered, un-fragmented.
However, it makes the code and testing more complex…

Best regards
Michael

---

From: Nagesh shamnur <[email-masked]>
Date: Thu, 9 Apr 2015 12:34:51 +0000

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: 09 April 2015 16:53
To: Nagesh shamnur
Cc: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-03.txt

> I-DATA[flags=BU; TSN=0;SID=0;MID=0;FSN=0] I-DATA[flags=EU; 
> TSN=1;SID=0;MID=0;FSN=0] I-DATA[flags=BU; TSN=2;SID=0;MID=1;FSN=0] 
I agree, that for un-ordered, un-fragmented user messages the MID is not important for the receiver.
However, I don’t want to make the I-DATA chunk header a variable size header. So the field is always there. From my perspective, it is simpler to require the sender to fill in the field always by incrementing it compared to state that it needs to be incremented always, except for un-ordered and un-fragmented user messages. The receiver will just not make use of it.
I don’t see any benefit it setting the field to some special value (like 0) for un-ordered, un-fragmented.
However, it makes the code and testing more complex…
On the contrary, can make the parameter dummy (setting to special value like 0) would be straight forward. Moreover, it would keep it consistent with the description of SSN in case of DATA Chunk. Ignoring of this value at the sender and ignoring at the receive would make it much simpler.
We needn't make the message having variable size header and keep the header size constant, but the sender can encode the value 0 and it can be ignored by the receiver for the case of unordered non-fragmented data.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 9 Apr 2015 21:18:02 +0200

> On 09 Apr 2015, at 14:34, Nagesh shamnur <[email-masked]> wrote:
> 
> 
In RFC 4960, it is not defined what the sender puts in the SSN field for unordered messages. It is
only stated that the receiver ignores it. See:
https://tools.ietf.org/html/rfc4960#section-6.6

I would like to make clear what the sender has to do. You are suggesting to treat un-ordered un-fragmented
user messages in a special way by always using MID 0. I’m proposing to not have special treatment
for them, just assigning a MID. This makes the sender side simpler: One if statement less to make.
The receiver doesn’t need to look at the value. So there is no difference at the receiver side.
> We needn't make the message having variable size header and keep the header size constant, but the sender can encode the value 0 and it can be ignored by the receiver for the case of unordered non-…
OK. So we agree that the chunk header is the same in all cases.

Best regards
Michael