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

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

Comments below...

Qiaobing Xie wrote:
> 
> 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.

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

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

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.

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

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.

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

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

> 
> -Qiaobing
> 
> Ian Rytina wrote:
> >
> > 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
> >
> > "Randall R. Stewart" wrote:
> >
> > > 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
> > >

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

---

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