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

From: [email-masked]
Date: Wed, 28 Feb 2001 10:39:15 +0200

Hi Randy,

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

That sounds like a solution to me!

br,
John

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

---

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

But how can this benefit the receiver? Seems to me the receiver will
still need to maintain and manage a re-assembly queue for each
unreliable stream and perform the same processing regardless of the N
value of a message. The problem is that the receiver won't be able to
know which messages coming out of the unreliable stream have N=0 and
which have N>0. Otherwise it can process them differently. Maybe I am
missing something here. 

-Qiaobing

---

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

Q:

The point is very simple.. not thinking of the uppe layers... you
cannot allow any fragmentation if N > 0. 

Now, as far as the application is concerned...

If N == 0
then
   Let  IP fragment it (or have SCTP insert IPv6 Fragmentation
   headers)
else
   Either DISCARD with error
     <or>
   Require SCTP to do fragmentation.
endif

What I am saying is you have a choice in the spec. Either
prohibit large messages when N > 0 <OR> specify in the
document that SCTP MUST do fragmentation and re-assembly
in this case.

Note that in IPv6 stacks you are stuck no matter what...since
IPv6 does NOT fragment and relies on the transport protocol
to insert a Fragmentation header... So no matter which
one you pick for the "else" above, you ARE going to have
to do fragmentation UNLESS you just disallow it all together...
Which I think is where we began :)

R

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