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

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 18 May 2006 13:16:49 -0700

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?

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?

> TCP should never assume 1500-byte segments; 576 is the
> assumption _unless other information is specifically available_.
> 

Technically it is the MPA layer doing the assuming, but you are
correct that MPA assumptions should be based on IETF standards
and not common deployment plans. For the common deployment situations
the EMSS will be available anyway, so 576 would be a better default.

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

---

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

> 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.

> 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.

> Technically it is the MPA layer doing the assuming,

Agreed.

> but you are