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

From: Qiaobing Xie <[email-masked]>
Date: Thu, 01 Mar 2001 10:37:21 -0600

Randy,

Let's discuss this issue at the Minn meeting. I think we have several
options here to explore.

regards,
-Qiaobing

"Randall R. Stewart" wrote:
> 
> Qiaobing Xie wrote:
> >
> > 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
> >
> > "Randall R. Stewart" wrote:
> > >
> > > 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...
> >
> > 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.
> >
> 
> 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...
> 
> > >
> > > >
> > > > 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 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.
> >
> 
> If you want to have bigger message (I am not sure why) this
> price must be paid...
> 
> > >
> > > 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.
> >
> > 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...
> 
> > >
> > > >
> > > > 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..
> >
> > 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...
> 
> 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
> 
> >
> > >
> > > 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)
> 
> --
> Randall R. Stewart
> [email-masked] or [email-masked]
> 815-342-5222 (cell) 815-477-2127 (work)

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