Subject: [Tsvwg] fragmentation and PMTU

From: Randall Stewart <[email-masked]>
Date: Mon, 14 Jan 2002 15:00:12 -0600

Dear All:

It has come to my attention that the following
is currently in RFC2960:

"
6.9 Fragmentation and Reassembly

   An endpoint MAY support fragmentation when sending DATA chunks, but
   MUST support reassembly when receiving DATA chunks.  If an endpoint
   supports fragmentation, it MUST fragment a user message if the size
   of the user message to be sent causes the outbound SCTP packet size
   to exceed the current MTU.  If an implementation does not support
   fragmentation of outbound user messages, the endpoint must return an
   error to its upper layer and not attempt to send the user message.
"

This all seems fine until one looks carefully at one little aspect:

- If I an implementation supports fragmentation it MUST fragment.

The issue I have with this is what if an application layer says:

"hey I know you can fragment, but please don't, I want you
 to reject sends that exceed the P-MTU."

This may be a perfectly reasonable behavior but the wording above
dis-allows that... I know the intent was to prevent folks from
just setting the DF bit and NOT doing P-MTU discovery... but what
we probably need here is a little clearification for the implementors
guide... something like.

"
 Note: If an implementation that supports fragmentation makes
 available to its upper layer a mechanism to turn off fragmentation
 it may do so. However in so doing, it MUST react just like an
 implementation that does NOT support fragmentation i.e. it MUST
 reject sends that exceed the current P-MTU.
"

I think this note (+wordsmitthing :>) would allow the behavior 
I mention above without harming the intent of the P-MTU/Fragmentation.

(Word smithing suggestions would be welcome here :>)

What do you'all think?

Thanks

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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

---

From: Michael Welzl <[email-masked]>
Date: 15 Jan 2002 12:34:10 +0100

>  to reject sends that exceed the P-MTU."

Couldn't we just say " ... it MUST be able to fragment" or something
like that?

> I mention above without harming the intent of the P-MTU/Fragmentation.

Sounds reasonable too. Maybe I just don't understand it.  :)
Those are the little necessities that make some RFC's hard to read ...

But this brings me to a different question about Path MTU Discovery (not
SCTP-related):

How is it implemented in real life?
RFC 1191 only makes suggestions about the layering, where PMTU
information is cached etc. - does anybody know the most common way to
implement it? Just layer 3? Initiated by TCP?

Cheers,
Michael

---

From: Randall Stewart <[email-masked]>
Date: Tue, 15 Jan 2002 06:44:15 -0600

> implement it? Just layer 3? Initiated by TCP?

Well lets see.. For TCP it is simpler than SCTP but
here is a rough run down on what happens...

When the ICMP message arrives a callback is generated 
to the specific protocol that launched the message that 
got the MSG_SIZE error out on the net. 

On the TCP side (found in tcp_subr on FreeBSD) the callback
hits tcp_ctlinput() with a PRC_MSGSIZE. The connection 
is found (if it can be) and then the tcp_mtudisc() routine is
called. This routine updates the mss and then looks to see
if it needs to do any output i.e. finds the data that was
just dropped and trys to resend it.. and since it is
a byte stream that is much easier than what SCTP has
to do :-0 (You can get better details than my quick
pass through the code .. with little coffee I might add ..
from Stevens TCP Illustrated Vol 2).

On the SCTP side we find the association, validate that
the V-Tag is correct. Then if all is good we proceed and
update the fragmentation threshold (PMTU variable kept). Once
we finish this we then walk through all the outstanding 
data chunks. If one exceeds the P-MTU (which may or may
not be the case) we mark it for resend AND set a flag that
will allow the IP_DF bit to be cleared (only V4 here). Then
we call the output which hopefully sends off our way-ward
packet. Note I said we may not find anything larger than
the PMTU in our chunk search.. this is because it may
have been a bundle of multiple chunks that exceeded the
PMTU size. For V6 if we are really smart we can try to
walk through the packet that was rejected and find the
specific chunks to mark for resend (my impl is too dumb
yet to do this though :0) for V4 we can't because we
only get (for sure) 8 bytes.. just enough to give us
the V-Tag and ports... so we may end up doing a t-o on
the chunk :-0

That more or less covers it.. for the SCTP details I
do cover some of it in the SCTP book ( the documentation
of the user space implementation in chapter 14 and
overview in 6.5) but to get a better view of a kernel implementation
you will probably have to wait to look at the 
new kernel code Peter and I are cranking on :0

We are almost done by the way .. :))

R

---

From: Stephen Bailey <[email-masked]>
Date: Tue, 15 Jan 2002 11:44:53 -0500

> [...]

No surprise, I'm for it (I've been agitating for this change for a
while).

It seemed like just an accident of wording that implementations that
CAN'T do fragmentation offer the ULP a guarantee that messages will
always be in a single chunk, where implementations that CAN do
fragmentation don't.  Personally, I'm going to run out and buy one of
those cool, unfragmenting implementations right now before they remove
them from the market :^)

As David points out, one reason for this change is to allow efficient
support of DDP in SCTP.  Another might be to permit simple processing
of unordered messages, perhaps for customized implementations of
particular ULP/SCTP pairs (maybe some telephony systems might be in
this category?).

Steph

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 16 Jan 2002 12:02:51 -0600

Randy,

I fully understand what you want to do with the implementation and I
think it can be a very useful feature for certain applications. However,
even with the current wording in RFC2960, I think it is already allowed
and if you do so nothing is going to be violated. In particular, there
is nothing in RFC2960 to prevent one from building a "dual-mode" stack
that can operate in either "fragmentation-capable" or
"fragmentation-incapable" state via an application controlled switch :-)

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Wed, 16 Jan 2002 12:34:06 -0600

Qiaobing:

I understand what you are after here but I think I dis-agree :0

I think we intended that if you can't fragment you get an error.
This is clearly stated in RFC2960. But if you read the words
carefully the only way you COULD disable fragmentation on
an implementation that is fragmentation capable is to "pretend"
that your flag made your whole stack incapable of fragmentation.

This is only because of our poor wording to try to prevent
folks from incorrectly implementing SCTP without PMTU discovery.

Now I think you are really streching when the same stack
may have one endpoint that has disabled fragmentation and another
that has NOT disabled fragmentation. Thus the stack is really
"streching" the truth if it trys to obey RFC2960 ... in order
to reject the sends...

I think the wording below is not harmful and prevents a stack
from violating the RFC by allowing the lee-way we should have
allowed in the first place :>

R