Subject: [Tsvwg] Why RDDP should work

From: [email-masked]
Date: Fri, 6 Dec 2002 23:09:06 -0500

Somewhere back near the beginning of  the "DO IT RIGHT" thread, Joe Touch
asked:

> Finally, I'd appreciate hearing a discussion of why this should all work 
> that doesn't include some glaring errors. E.g., at the last meeting we 
> all heard about how TCP with Nagle off (NODELAY) sends packets that 
> match what the send calls issue. That simply isn't the case, never was, 
> and cannot be assumed regardless. E.g., how do you know the path MTU 
> didn't change between when you checked it/issued the write and when the 
> packet is emitted?
> 
> Many of the other debates about these other protocols ignore the fact 
> that the TCP spec is defined in terms of two interfaces - one 
> below (the packets) and one above (the API, in terms of generic 
> SEND/RECV/OPEN/CLOSE etc.) The API appears to be ignored in 
> most cases.

I think much of the answer is in the following message that I recently
posted to rddp, but not tsvwg:

-----Original Message-----

[... headers snipped ...]

> The first question that needs to be answered is:
> 
> 	Is the spec going to explicitly sanction the processing
> 	of out-of-order TCP segments, and is there buy-in from
> 	the ADs, TSV and/or IESG?

I believe that can be answered with a qualified "yes" based in part
on the discussion at the tsvwg meeting in Atlanta, and also on
the discussion of shared buffers in RFC 793.  The qualification
involves separation of placement (received bytes go into a buffer)
from delivery (that buffer is passed to the application or protocol
above TCP/MPA) - out-of-order placement is acceptable, but out-of-order
delivery is not, and the next version of the MPA draft will need an
explicit buffer ownership model and specification that forbids the
upper level app/protocol from looking at memory that may contain
placed data that has not been delivered.

While there is some degree of AD and TSVWG buy-in, I would not want
to characterize it as a blank check.  As I've said before, whatever
the WG proposes to do in this area will be held to a high technical
standard.

---End of Original Message---

The rest of the answers to Joe's specific issues are roughly:
- The Nagle comment was wrong both for the reason Joe gave above
	(and Randy Stewart confirmed) and because Joe is correct
	that TCP sender behavior is part of the TCP specification.
- 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 :-(.  
- Better discussion of placement vs. delivery and the explicit
	buffer ownership model (including a "thou shalt not touch
	placed data that has not been delivered" rule) should go
	a long way towards addressing consistency with the
	generic API.

With luck, the foregoing has managed to avoid "glaring errors".

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Dec 2002 21:50:47 -0700

David,

> 	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