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

From: [email-masked]
Date: Tue, 27 Feb 2001 11:10:32 -0600

Hi, John:

May I jump in the discussion?

-----Original Message-----
> From: Loughney John (NRC/Helsinki) 
> Sent: 27 February, 2001 6:55 AM

> Case 2: SCTP level frag, reliable transport

> SCTP packet A is larger than MTU, so SCTP fragments it into SCTP packet 
> A1 & SCTP packet A2.  SCTP packet2 gets lost, so SCTP retransmits
> only packet A2.

> Case 3: IP and/or SCTP level frag, unreliable transport

> If a packet is fragmented at SCTP or IP, it doesn't matter much,
> because it won't be retransmitted.

Well, if I understand correctly, one difference between unreliable
SCTP and conventional unreliable data service (e.g. UDP) is that,
when using SCTP, it is possible to control the number of desired
retransmissions if needed for unreliable data delivery.  This means
that it could somewhat resemble (but NOT exactly the same) to the
situation discussed in Case 2.  Indeed, we can consider transporting
data under unreliable service with "infinite" number of retransmissions
is conceptually equivalent to that under reliable service.  Do you agree?

Just my 2 cents.  Comments are appreciated!

BR,
Cheong

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 27 Feb 2001 13:12:21 -0600

Exactly my point in my last email.. I think
we need to take a closer examination of this
in the next pass of the document.

R

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

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 27 Feb 2001 13:30:19 -0600

The key is to understand how much implementation complexity the receiver
will need to add in order to handle this. In comparison, the change to
the spec will be relatively small if we decide to allow this.

-Q

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 27 Feb 2001 14:40:58 -0600

Q:

I agree with you in principle. Doing the fragmentation and
tracking it would get kind of messy...

But we must do something if the N>0 in the retransmit parameter.
Maybe we should REQUIRE with a MUST the fragmentation at the
SCTP layer if and only if the retransmit value is >0...

R

---

From: Ian Rytina <[email-masked]>
Date: Wed, 28 Feb 2001 15:52:17 +1100

Hi Qiaobing,

I am not sure I follow your argument about implementation
complexity. Doesn't most of this fragmentation/tracking already
exist for the reliable stream case ?

/Ian

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 28 Feb 2001 11:41:58 -0600

Ian,

The new complexity that would need to be added to the receiver is: 

1. the receiver will need to create and maintain a re-assembly queue for
each unreliable stream. This can be omitted if we choose not to support
unreliable fragmentation.

2. every time a Forward TSN arrives the receiver will need to go into
each unreliable stream's re-assembly queue to find out and discard any
partially reassembled messages that are still waiting for missing TSNs
beyond the new cumulative TSN reported in the F-TSN. This can be quite
messy.. 

When coming to unreliable data transport, one would normally hope that
it will come with low delay and low processing overhead like what UDP
provides. On the other hand, with reliable transport, people are more
willing to trade some processing overhead and delay for the reliability.

The drawback of the above mechanism would be that every unreliable
message will be equally penalized by the additional processing overhead
regardless whether it is a completely unreliable message (ie, N=0) or a
limited reliability message (ie, N>0).

But if we choose not to support the above unreliable fragmentation by
SCTP but leave it to the IP layer, the retransmission inefficiency
penalty will only be paid by those unreliable messages with N>0, and the
more reliability you want on the message (ie, the bigger the N is), the
more potential retransmission inefficiency penalty you may have to pay.
This seems fairer to me.

-Qiaobing

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 28 Feb 2001 13:29:38 -0600

Comments below...

> unreliable fragmentation.

I don't think I need a queue for each stream. I currently must
maintain a queue that is being re-assembled (below any stream
sequence processing). When a FWD-TSN arrives I would need to
look on this queue. Any TSN's on this queue would then have to
be jetisioned if they are covered by the FWD-TSN. This is
just a extra step in FWD-TSN processing. You may also want to
verify that the jetisonee's are in a u-sctp stream of course...

> beyond the new cumulative TSN reported in the F-TSN. This can be quite

This is the same argument that Renee Revis mentioned about wanting
to have stream numbers in the FWD-TSN. We (the authors) decided
in San Diego that one could hash u-sctp packets pending delivery
(waiting for a previous SSN) and then go look them up this way.

I only see one addtion to the above, we go and look at the single
re-assembly queue when a FWD-TSN arrives. These are normally kept
has a ordered list so most likely one comparison is all that
will be needed here.

> limited reliability message (ie, N>0).

How would you penalize each U-SCTP message? You receive a u-sctp data
chunk. If it is IN-ORDER you delivery it without delay (fast-path). If
it is NOT in order you park it... this is the same with reliable and
u-sctp... I don't see any difference here.

> more potential retransmission inefficiency penalty you may have to pay.

I don't see you escaping this problem anyway.. think IPV6!!! You
MUST implement this... OR specifically disallow larger than P-MTU
size packets..

R

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 28 Feb 2001 17:07:38 -0600

Randy,

Like I said earlier, I am not convinced either way. But I want to point
out the complexity associated with supporting unreliable frag. 

More comments inline...

-Q

> verify that the jetisonee's are in a u-sctp stream of course...

You pointed out an alternative way of implementing it if I understand
you right. You are basically proposing to use the same re-assembly queue
for both the reliable and unreliable streams. With this approach, the
extra processing step is still there since if we don't support
frag/reassembly of unreliable message at SCTP layer, the receiver will
not need to look at the *re-assembly* queue and jettison any thing there
when processing a FWD-TSN.

> (waiting for a previous SSN) and then go look them up this way.

I remember Renee Revis's comments were about the maintenance of the
*re-ordering* queue at the stream level by the receiver when processing
a FWD-TSN. This is always the case with or without unreliable
fragmentation. But to support unreliable frag., the same queue
maintenance issue will arise at the re-assembly level as you noted
above. And this is the extra price to pay.

> u-sctp... I don't see any difference here.

Again, the issue is not *re-ordering*, but *re-assembly*.

> MUST implement this... OR specifically disallow larger than P-MTU

I am not sure how UDP runs over IPv6. Does it need to either perform
UDP-level fragmentation and reassembly or reject messages larger than
the current P-MTU? I think U-SCTP is in the same situation as UDP is in
this regard. If UDP has to do its own fragmentation to run over IPv6, I
will have no further argument...

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 28 Feb 2001 18:06:12 -0600

> when processing a FWD-TSN.

Yes, but this is a price only paid when you process the FWD-TSN and
it should be only a few comparisons at most...

If you have to small of messages then you wont have a issue and
the cost will not be there...

> above. And this is the extra price to pay.

If you want to have bigger message (I am not sure why) this
price must be paid... 

> Again, the issue is not *re-ordering*, but *re-assembly*.

Yes but they can be handled together...  You are missing my
point about order.. when you receive things in order they
can run on a fast-path through the code...

> will have no further argument...

I have just been digging through the kame stack..

ALL transport protocols on IPv6 must do the fragmentation however
has an implementation decision it can be done by the IP layer if
one were to choose to build a common fragmentation set of code..

I think this is what kame did but it is NOT part of the spec but
an implementation detail...

I will know a bit more tommorrow...

No matter what the case, the IPv6 spec is crystal on this ...i.e.
it is the transport protocols responsibility to do
fragmentation/reassembly.
There is fragmentation header extensions for this purpose but IPv6 
"conceptually" does not do the frag/re-assembly.. you can choose
to implement it that way or not... it depends on the IP stack..

R