Subject: RE: [Tsvwg] Why RDDP should work

From: [email-masked]
Date: Sat, 7 Dec 2002 00:10:24 -0500

Brian,

The problem scenario involves retransmission of a chunk that
exceeds PMTU size on all available paths.  The specific text
in RFC 2960 is quite clear (Section 6.9):

   Note: Once a message is fragmented it cannot be re-fragmented.
   Instead if the PMTU has been reduced, then IP fragmentation must be
   used.  Please see Section 7.3 for details of PMTU discovery.

I agree that there are lots of things that can and should
be done so that getting backed into this corner is very
rare, but if an implementation nonetheless arrives in this corner,
it's stuck (in 20/20 hindsight, it should have fragmented
the chunk in question, but it's a bit late to figure that out).

Thanks,
--David

> David,
> 
> On Fri, 06 Dec 2002, [email-masked] wrote:
> 
> > - The specific area of path MTU reduction is not pretty for a framed
> > 	and aligned protocol.  If PMTU reduction occurs after
> > 	transmission of a frame that needed the larger PMTU, and
> > 	that frame needs retransmission, SCTP resorts to IP
> > 	fragmentation in order to avoid breaking alignment :-(.  
> 
> Not completely correct.  There is no requirement on an SCTP
> sender to completely pack DATA chunks to a PTMU.  The SCTP
> sender is permitted to fragment to smaller DATA chunks.  There
> are, in fact, several reasons to do this: one being so that
> the resulting DATA chunks is likely to fit in a packet along
> with a SACK chunk on retransmission.
> 
> When performing NAGLE on SCTP, it behooves the sender to pack
> DATA chunks only until the packet is only half-full.
> 
> When DATA chunks do not fill the entire packet, it is possible
> to retransmit them separately in smaller packets on
> retransmission should PMTU fall.  Setting the maximum DATA
> chunk size (similar to a user-specified MSS in TCP)
> properly can ensure that IP fragementation never occurs on
> DATA (by setting this DATA chunk MSS to the minimum PTMU).
> 
> Actually the above can be done with TCP, but with far less
> efficiency.  SCTP can frag data down into small DATA chunks
> and then bundle them back up in packets.  Setting TCP's MSS
> low would mean that TCP will send small segments in each
> packet rather than utilizing the whole packet.
> 
> Additional possibilities include:
> 
> When SCTP is multi-homed, it is possible to retransmit these
> TSNs on a path whose PTMU has not fallen.
> 
> Also, initial packets are always sent DF and retransmissions
> only need to use IP fragmentation if TSNs subsequent to the
> failed TSN have already been transmitted in a subsequent
> packet.  Otherwise, it is possible to rewalk the retransmit
> queue and refragment the DATA chunks.
> 
> If the SCTP receiver could be made to skip checking for
> monitonically increasing SSNs with increasing TSNs, with
> PR-SCTP it could be possible to outdate the offending TSNs,
> and refragment the DATA chunks (with the same SSNs) into new
> TSNs.
> 
> Proper PTMU discovery (with padded HEARTBEATS) should catch
> most falling PTMU cases before the data chunks even make it to
> TSN assignment.
> 
> But the best approach is setting the maximum DATA chunk size
> to the minimum PMTU (minus overhead).
> 
> So, no need to resort to IP fragmentation.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Dec 2002 11:49:46 -0700

Black_David,

Actually an SCTP implementation can stay out of the corner
always: it fragments DATA chunks down below the minimum IP
MTU and then bundles them back together on the first transmission.
It can then never be faced with IP fragmentation, because all
DATA chunks will fit into the smalles IP packet.

So, in SCTP is is possible to address falling PMTU.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Dec 2002 13:14:37 -0700

Caitlin,

If TSNs are never assigned to DATA chunks larger than the
minimum IP MTU (i.e. if DATA chunks are always fragmented to
minimum IP MTU), then when an ICMP error occurs, SCTP merely
retransmits the already fragmented DATA chunks with the new
PMTU bundling and no IP fragmentation is ever necessary.

--brian

On Mon, 09 Dec 2002, Caitlin Bestler wrote:

> On 12/9/02, Brian F. G. Bidulock wrote:
> 
> >Black_David,
> >
> >MTU and then bundles them back together on the first
> >transmission. It can then never be faced with IP
> >fragmentation, because all DATA chunks will fit into the
> >smalles IP packet.
> >
> Once TSNs have been assigned, they cannot be reassigned.
> If an ICMP error is returned, the sender MUST use IP
> fragmentation unless there is an alternate path that still
> has an adequate PMTU.
> 
> Implementations will vary on how quickly TSNs are assigned,
> which will affect the scope of exposure.
> 
> Caitlin Bestler
> http://asomi.com/CaitlinBestler/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Dec 2002 14:03:23 -0700

Caitlin,

On Mon, 09 Dec 2002, Caitlin Bestler wrote:

> >minimum IP MTU (i.e. if DATA chunks are always fragmented
> >to minimum IP MTU), then when an ICMP error occurs, SCTP
> >merely retransmits the already fragmented DATA chunks with
> >the new PMTU bundling and no IP fragmentation is ever
> >necessary.
> >
> 
> RFC 2960 - Section 6.9:
> 
> >   Note: Once a message is fragmented it cannot be 
> >   re-fragmented. Instead if the PMTU has been reduced, 
> >   then IP fragmentation must be used.  Please see Section 
> >   7.3 for details of PMTU discovery.
> 
> If TSN N has been rejected because of a PMTU error, but N+1
> already made it through then there is simply no way to break
> N into two messages at the SCTP layer. What would the TSN of
> the second message be?

The TSNs are the same as in the original transmission.  They
are just bundled fewer to a frame to meet the new PTMU.

SCTP only need invoke IP fragmentation if it cannot bundle
an existing DATA chunk into the new PTMU (because the DATA
chunk is too big for the PTMU).  If DATA chunks are never
greater than the minimum IP MTU in the first place, then they
can always be bundled on retransmission to fit into the new
PMTU and invoking IP fragmentation is not necessary.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 9 Dec 2002 14:44:33 -0700

Caitlin,

The overhead is only significant if the normal MTU is much
greater than the minimum IP MTU.  This is not the case for
normal Etherenet (3:1) where the overhead would simply be
2 DATA chunk headers for a total of 48 bytes.

For extremely large MTUs there could be significant overhead,
however, one would not want to ever mix minimimum IP paths
with such high performance paths.  Setting the DATA chunk
fragmentation to the minimum experienced IP MTU would work
well in those situations, particularly if IP fragementation
is to be completely avoided.

The point is that falling PMTUs need not wreak havoc with
SCTP as was originally implied.

--brian

On Mon, 09 Dec 2002, Caitlin Bestler wrote:

> But isn't fragmenting Data Chunks to the *minimum* IP MTU
> particulary inefficient when dealing with large transfers?
> 
> It would strike me as a very poor choice for most RDDP
> applications. If the connection is carrying enough traffic
> to justify RDDP then adding signifigant overhead to avoid IP
> fragmentation just wouldn't seem to make sense.