Subject: [rddp] Markers: Requirements and issues

From: [email-masked]
Date: Wed, 4 Dec 2002 02:01:51 -0500

With my WG chair hat off, this is an attempt to collect issues
from the past day's discussion of markers into a single email:

(1) Can loss of alignment be made sufficiently rare to allow
	it to be treated as an error case, and close connections?

A couple of related notes:
- Our AD has asked the WG to provide strong assurances that two
	communicating TCPs (modified or not) cannot get confused
	about whether traffic is framed or not. This sounds like
	a component of a situation in which a receiver could
	assume that traffic is framed.
- A persistent CRC error (not correctable via retransmits) is
	fatal to an MPA connection.  That's an error case in
	which the only choices are connection closure or livelock,
	for a connection on which useful data has been sent.
	One would hope that it's rare (and design to make it so).

(2) What are all the causes of loss of alignment, and what are
the options available to minimize or deal with them?

Some fairly ugly handling can be justified to deal with rare ugly
situations.  For example, there's a nasty combination of SCTP
fragmentation, a drop requiring retransmission, and a PMTU size
change that forces SCTP to resort to IP fragmentation (see the
fourth paragraph in Section 6.9 of RFC 2960).

(3) What is the actual situation regarding existence/deployment of
	resegmenting middleboxes?

IMHO, it would be good to get closer to brass tacks in this discussion.
For example, what is likely to be encountered as common resegmenting
middlebox functionality, and what are the corresponding deployment
scenarios?  This could help illuminate whether the "training sequence"
approach to getting a resegmenting middlebox to show itself is realistic.

(4) Does the resegmentation have to be detected before placement
	of subsequent data in the bytestream?

While I think this issue is open, I acknowledge Paul Culley's
strong "no" viewpoint on this, on the grounds that an erroneous
placement is unrecoverable and can cause invalidation of memory
that would not need to be invalidated if the connection closed due
to a CRC failure.

(5) Can markers and the marker interval be negotiable?

This is Tom Talpey's suggestion, and would help deal with a
couple of practical issues that markers raise:
- The tax on software implementations of the 512-byte interval.
- The existence of situations in which one can be sure that markers
	are not needed (e.g., end-to-end IPsec integrity is an absolute
	bar to resegmenting middlebox mischief).

The above list is not complete and should not exclude other issues 
from discussion.  It would be a good idea to break issues out into
separate emails to the list *with different headers* when responding.

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
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Somesh Gupta" <[email-masked]>
Date: Wed, 4 Dec 2002 09:50:22 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, December 03, 2002 11:02 PM
> To: [email-masked]
> Subject: [rddp] Markers: Requirements and issues
> 
> 

  Is this TCP level retransmission (i.e. CRC verification prior
  to TCP ack generation) or an upper layer retransmission such
  as in iSCSI?