Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request

From: Randall Stewart <[email-masked]>
Date: Thu, 01 Jun 2006 10:55:57 -0400

Joe Touch wrote:

> Yes. With retransmission alone all bets are off.
> 
> This is the Nth time this dog has been dragged around the block.
> 
> It also assumes that the sends match the PDUs; if they're ever larger, 
> that and all subsequent segments will be misaligned in those 
> implementations. How do you know when the path changes? There are no 
> signals in TCP's API to tell the app when the MTU changes, or - more 
> importantly - to tell them that it changed and all the queued data will 
> be segmented differently.
> 
> This is just a bad idea.

Joe/All:

Ok, I have read through this thread.. quite late.. and have
a question related to the above... I get how a retransmission will
cause resegmentation... and mess up MPA.. but is there not another
case that no one as brought up that happens more on the norm...

Consider a MPA sender sending 512 byte blocks (I do this
for convience almost any size will do).. and assume we
have a LOT of these to send... say at least 10.

Now lets start with an intial cwnd = 4380...

Now we start sending are 512 byte blocks

1:----send(512)----> to wire
2:----send(512)----> to wire
...
8:----send(512)----> to wire
9:----send(512)----> XXXX
10:---send(512)---->

At the XXXX above we would NOT send the whole thing
on the wire.. instead you will get 284 bytes sent
to fill the cwnd. When the first ACK comes back
you will then get the rest+512 bytes out...

This is a NORMAL non-retransmission scheme where this
would happen on a regular basis in a LOT of different forms..

Would not this cause additional issues... now I am by far
not a TCP expert... not unless you flip two letters and stick
an S in front of it :-D

But we have seen an issue like this with SCTP... where we have
to allow a "slop" over the cwnd otherwise the cwnd never grows...
TCP never had this problem.. since if there was just a bit
of room it can re-segment and transmit just a small piece to
fill the cwnd exactly....

It seems to me this is an additional issue that one will find
with "standard" TCP stacks.. and for new stacks they build
to do MPA they will run in to the issue that they stop at
segment 8 (above).. and then when the sack arrives they
can send there segment.. but this also means (at least
IMO) they are NOT using the full cwnd.. and thus should
NOT be allowed to grow it ...

A rather interesting issue that they need to address (if they have
not already).. I confess I have not read the MPA draft anytime
recently... so they may have a work-around for this...

Just some thoughts.. late though they are :-D

R
-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

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

---

From: "Culley, Paul" <[email-masked]>
Date: Mon, 19 Jun 2006 14:50:51 -0500

Randall:

Regarding the case you describe below; it is my impression that it is an
allowable (possibly common) practice in TCP to manage the cwnd in
segments. RFC2581 includes some notes on how to deal with cwnd in
segments in section 3.1.  

Furthermore, when there is enough data to fill segments, I would expect
that implementations do fill them completely.  To avoid cwnd violations,
I assume that it is allowed to not actually send a segment until the
cwnd is large enough to fill one.  Seems like partly filling segments
due to a small cwnd would lead to un-necessary small packets, extra
overhead etc., the same kind of thing that other RFCs advise against
doing for other reasons (silly window etc.).

I have not been able to find any suggestion that it is not legal to
increase cwnd unless you fully fill it; if you can point me to the
appropriate text in an RFC I am willing to be educated.

So the issue that you raise below need not be a problem for MPA-aware
TCP stacks.  I agree that there are various reasons that a standard TCP
stack can lose segmentation, even with Nagle disabled, and your example
may be one of them.  However even in those cases, the way that DDP/MPA
is usually used will tend to have breaks in the data stream where the
transmit buffers drain.  This will tend to re-establish segmentation.
Also, the MPA draft is clear that receivers MUST operate even when
segmentation is not occurring.

Paul R. Culley
HP Fellow
281-514-5543

-----Original Message-----
From: Randall Stewart [mailto:[email-masked]] 
Sent: Thursday, June 01, 2006 9:56 AM
To: Joe Touch

Joe/All:

Ok, I have read through this thread.. quite late.. and have a question
related to the above... I get how a retransmission will cause
resegmentation... and mess up MPA.. but is there not another case that
no one as brought up that happens more on the norm...

Consider a MPA sender sending 512 byte blocks (I do this for convience
almost any size will do).. and assume we have a LOT of these to send...
say at least 10.

At the XXXX above we would NOT send the whole thing on the wire..
instead you will get 284 bytes sent to fill the cwnd. When the first ACK
comes back you will then get the rest+512 bytes out...

This is a NORMAL non-retransmission scheme where this would happen on a
regular basis in a LOT of different forms..

Would not this cause additional issues... now I am by far not a TCP
expert... not unless you flip two letters and stick an S in front of it
:-D

But we have seen an issue like this with SCTP... where we have to allow
a "slop" over the cwnd otherwise the cwnd never grows...
TCP never had this problem.. since if there was just a bit of room it
can re-segment and transmit just a small piece to fill the cwnd
exactly....

It seems to me this is an additional issue that one will find with
"standard" TCP stacks.. and for new stacks they build to do MPA they
will run in to the issue that they stop at segment 8 (above).. and then
when the sack arrives they can send there segment.. but this also means
(at least
IMO) they are NOT using the full cwnd.. and thus should NOT be allowed
to grow it ...

A rather interesting issue that they need to address (if they have not
already).. I confess I have not read the MPA draft anytime recently...
so they may have a work-around for this...

R

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jun 2006 13:21:26 -0700

> segments. RFC2581 includes some notes on how to deal with cwnd in

Allowable, possibly common, but not required. The application layer must
assume what TCP is allowed to do, NOT what an individual implementation
of TCP happens to do (even if detected). There are no rules that TCP
must be consistent in applying rounding of CWND to SMSS, or even that
SMSS must be static over the life of a connection.

> doing for other reasons (silly window etc.).

This assumption is based on how Nagle works; note that Nagle-ON means
that a TCP will limit the partial outstanding (as yet un-ack'd) segments
to one; it does NOT mean that only full segments will ever be sent. As
noted in section 3.1 of RFC2581, there are equations that don't make
sense if treated solely in terms of full segments.

> appropriate text in an RFC I am willing to be educated.

That's correct; the issue isn't whether it needs to be filled, but that
there is NO option at the application API in TCP to say "send only full
segments". Again, this is a place where there appears to be an
assumption in MPA that has been made many times before; I'll state the
real issues again:

	there is NO guaranteed correlation between data boundaries
	in TCP's API (i.e., send/receive) and segments on the wire

	there is NO rule that a TCP which happens to break messages
	on API boundaries will continue to do so in the future, even
	if it has done so in the past

> transmit buffers drain.  This will tend to re-establish segmentation.

That is a false conclusion. What a particular implementation will do
regarding segmentation is up to that implementation.

> segmentation is not occurring.

This is fine, but to assume - or even expect - the optimization of
boundary preservation is inappropriate; it is based on an implementation
property that the protocol not only does not guarantee, it specifically
allows.

Joe