Subject: [Tsvwg] Re: SCTP and IP Frag aliasing on LFNs

From: [email-masked]
Date: Wed, 27 Feb 2002 22:14:22 EST

I have read of some routers doing what I will casually term:

 - TCP fragmentation (spreading the TCP level payload into two consecutively 
sequenced and not fragmented TCP-IP packets) and

 - TCP aggregation (merging sequentially adjacent TCP packets into fewer 
packets that fit the local MTU).

This can help bridge an unexpected MTU bottleneck, and does not degrade 
packet reliability as much as IP fragmentation, since if the second packet is 
lost, you get 50% throughput (short term) not 0%.

Is it possible that routers could be written to do this sort of gratuitous 
packet rewriting with SCTP, or does the SCTP protocol and checking implicitly 
prevent it?

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 28 Feb 2002 13:28:21 -0600

Similar (but not exact) thing can be done with SCTP. For example, if a
router gets an SCTP packet which carries multiple data chunks and is too
big for the MTU of the next hop, it could in theory split the
multi-data-chunk SCTP packet into multiple SCTP packets of smaller size
and forward them on. But there is no guarantee that each of the
resultant packets will fit into the MTU. If you want to further fragment
an oversized data chunk into small pieces, there will be problems with
SCTP. This is because SCTP is message-oriented and it has to preserve
the boundaries of the original user message. TCP has no such constrain
and can therefore split (or combine) data segments without worrying
break the protocol semantics.

-Qiaobing

[email-masked] wrote:
> - TCP fragmentation (spreading the TCP level payload into two
> consecutively sequenced and not fragmented TCP-IP packets) and
> 
> - TCP aggregation (merging sequentially adjacent TCP packets into
> fewer packets that fit the local MTU).
> 
> This can help bridge an unexpected MTU bottleneck, and does not
> degrade packet reliability as much as IP fragmentation, since if the
> second packet is lost, you get 50% throughput (short term) not 0%.
> 
> Is it possible that routers could be written to do this sort of
> gratuitous packet rewriting with SCTP, or does the SCTP protocol and
> checking implicitly prevent it?

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