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

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 18 May 2006 14:09:02 -0700

Joe Touch wrote:
> Caitlin Bestler wrote:
>> Joe Touch wrote:
>> 
>> 
>>> 3.1.1 incorrectly assumes that turning Nagle off will correlate
>>> sends with segment boundaries; TCP is under _no_ obligation to do
>>> this. possible changes in pmtu would definitely change that behavior
>>> 
>> 
>> To be precise, 3.1.1 suggest that when MPA works above TCP it might
>> want to use TCP_NODELAY because it "will usually result in many of
>> the segments starting with an FPDU".
>> 
>> Do you dispute that this is an accurate comment on the *probable*
>> behavior, and that in fact using TCP_NODELAY is likely to increase
>> the correlation between MPA FPDUs and TCP Segments?
> 
> 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.
> 
>> Certainly enabling Nagle would decrease the frequency of aligned MPA
>> FPDUs, so I don't see how a suggestion on how a user of TCP picks
>> already defined TCP options is in anyway wrong unless the advice
>> being given is in fact counter-productive. In the worst case setting
>> TCP_NODELAY will be ineffective.
>> 
>> I believe the draft is already clear on that point, do you disagree?
> 
> I don't see the point in endorsing this approach. It sets up
> the expectation that TCP does something; when it doesn't
> they'll complain that the TCP isn't MPA-friendly. IMO, MPA isn't
> TCP-friendly to expect *any* correlation between sends and segments,
> period. 
> 
> Again, this dog has been dragged around the block (kicking and
> screaming) before. 
>

MPA does not do anything over TCP that any low level daemon could
not do. And the optimization strategies it suggests are valid. 
Retransmission alone can and will break MPA alignment, but if
retransmission represents the norm there are some severe problems
with the network.

MPA is a ULP to TCP that has a strategy to increase the probability
that a received TCP Segment will contain a complete MPA FULPDU.
I think it is clear that the strategy specified is in fact effective,
but I do not think that is relevant for the TCPM discussion.

As I see it the relevant question here is if MPA is recommending a
pattern of TCP usage that would somehow be disruptive of TCP's
on an end-to-end global basis. For example, if someone were to
write a spec for "XYZ" that said that an "XYZ friendly" TCP sender
would not bother to constrain itself based on congestion then the
XYZ draft would definitely be guilty of undermining TCP.

An "MPA Friendly" TCP sender does not do anything that an existing
TCP sender might already do to implement TCP_NODELAY. Further, the
number of TCP Segments where that is relevant is exceedingly small,
since most MPA FULPDUs will fill an entire TCP segment.

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 May 2006 15:23:13 -0700

Caitlin Bestler wrote:
...
> retransmission represents the norm there are some severe problems

...
> on an end-to-end global basis.

Not assuming retransmission would fall into that category, IMO.

Joe

---

From: Ted Faber <[email-masked]>
Date: Thu, 18 May 2006 15:38:51 -0700

> Not assuming retransmission would fall into that category, IMO.

Ummmm, how so?

Unless I misunderstood Caitlin, the only entity suffering from problems
if TCP retransmissions are common is the MPA.  It won't cause congestion
collapse or any harm to the network, will it?  Am I missing a danger to
other TCP connections?

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 May 2006 15:59:35 -0700

> collapse or any harm to the network, will it?  Am I missing a danger to

What I'm suggesting is having MPA spec a use of TCP that works only when 
TCP doesn't happen to do retransmissions.

You're right that this wouldn't disrupt other TCPs, but IMO it's a waste 
of time. TCP is designed for retransmission; if you have an application 
protocol that works best or only if there aren't any, then you ought to 
be using a different transport protocol.

Joe