Subject: RE: [Tsvwg] fragmentation and PMTU

From: "Arias-Rodriguez Ivan (NRC/Helsinki)" <[email-masked]>
Date: Tue, 15 Jan 2002 14:20:29 +0200

Hi Randall!

	Some comments inline...

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

	Excuse my ignorance, but, why would you like such kind of
behavior? Couldn't the upper user simply discard those messages
beforehand? The upper user should be aware of the variations in the
P-MTU but... :-/

	Now that I think about it... About the socket extension...
Wouldn't it be a good idea to include a spinfo_pmtu parameter in the
struct sctp_paddrinfo (8.7.2)? Otherwise, AFAIK there is no way to know
about the MTU at all...

	Maybe the struct sctp_status (7.2.1) could also contain a
sstat_mtu field... This would be the lowest of all the P-MTUs... If you
are sending messages bigger than that value, you know they will be
fragmented (because you can never know to which address they will be
sent/retransmitted)...

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

	Well, I think the Note doesn't damage to anybody. I'm just
curious why somebody would like to behave like that... (uhm, I think I
have made to myself this same question in some other situations... :->)

	BR Iván Arias Rodríguez

> Thanks
> 
> R
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 15 Jan 2002 08:16:34 -0600

> beforehand? The upper user should be aware of the variations in the

One place such a thing MIGHT be wanted is in something like
SCSI over IP... there are other applications as well that
may NOT want to ever send anything over a PMTU. 

We may not be able to come up with more than one or so
applications that do this now.. but why exclude a behavior
that some future app's may also want for no good reason...

> struct sctp_paddrinfo (8.7.2)? Otherwise, AFAIK there is no way to know

This is a GOOD suggestion. We could put this in the association
status field SCTP_STATUS... something like sctp_fragmentation_threshold

This may be differnt than the individual P-MTU's.. but we probably
should ALSO include this in the paddr_info as well...

If none of my co-authors have an objection I will add these in for
the next spin :>

> fragmented (because you can never know to which address they will be

Yep, fragmentation threshold... most implementations use the
lowest MTU of all destinations for this... 

> have made to myself this same question in some other situations... :->)

I believe also Doug Otis posted something along this line
as well for RDMA... not sure of the details.. I will have
to go back and look in the email archives...

R