Subject: Re: [Tsvwg] RE: [rddp] RE: Placement "outside of" TCP

From: David Borman <[email-masked]>
Date: Thu, 19 Dec 2002 15:37:05 -0600 (CST)

> Date: Thu, 19 Dec 2002 13:02:26 -0800
> From: Joe Touch <[email-masked]>
> Subject: Re: [Tsvwg] RE: [rddp] RE: Placement "outside of" TCP
...
> > optional resequencing point may also be delivered.  If TCP had this
> > extension, then the whole MPA marker issue goes poof and is gone,
> > and the DDP/TCP spec becomes much cleaner from a protocol design
> > point of view.
>
> Perhaps, but that would require that the extended TCP be activated 
> deliberately, i.e., off by default.

Absolutely!  I wouldn't have it any other way!

...
> Further, out-of-order is part of the issue; the other part regards 
> segments. The MPA assumes that 'compliant implementations' will pass 
> application segments as a whole as single TCP segments, and that the 
> receiver MPA can detect when that's not the case. However, the intent is 
> that a set of implementations will abide by those rules, effectively 
> changing the API.

DDP already is allowing multiple ULPDUs to be packed into a single
segment, and ULPDUs can be larger than the underlying MSS, thus
spanning multiple TCP segments.  So implementations already have to
deal with TCP segments that don't begin a ULPDU, and ULPDUs that
begin in the middle of a TCP segment.

Implementations can optimize their sending/receiving to generate/process
ULPDUs that are aligned at the start of a TCP segment without changing
the API.

So I view aligning ULPDUs on TCP segment boundries as an implementation
optimization, it doesn't need to be part of the protocol design.  They
have to deal with unaligned ULPDUs anyway.

(Then there is the other alignment issue, the fact that MPA pads all
the ULPDUs to 4 octet boundries.  But the only reason for that is because
markers dictate it.  Remove markers, and you don't need the padding.)

		-David Borman, [email-masked]
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Dec 2002 14:27:55 -0800

David Borman wrote:
...
> have to deal with unaligned ULPDUs anyway.

Except that if the ULPDU traverses TCP segments, it's possible that 
there will be interactions with, e.g., Nagle or ack compression that 
cause 200 ms (typically) timing delays.

My impression is that these protocols would be _much_ better off, if not 
'requiring' (at least for the performance optimization aspect) that the 
TCP segment break on an ULPDU boundary (agreed, though, that I was 
imprecise in assuming that there would be a 1:1 match).

Joe