Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

["Scheffenegger, Richard" <[e-mail]>]

> 
> However, now you're back to the NIC issue (which ought not be related):
> 
> > In their IMC paper entitled "Is it Still Possible to Extend TCP?",
> > Michio Honda et al. provide the following recommendation
> > http://conferences.sigcomm.org/imc/2011/docs/p181.pdf
> >
> > "All the NICs we tested correctly copied the options to all the split
> > segments. TSO is now sufficiently commonplace so that designers of
> > extensions to TCP should assume it. The implication is that TCP
> > options must be designed so that when they are duplicated on
> > consecutive segments, this does not adversely affect correctness or
> performance."
> 
> This tells me your TCP interface was implemented incorrectly.
> 
> The correct interface passes options (including the extended option *and
> its associated contents*) ***SEPARATELY*** from the user data.
> 
> If that is done all the way down to the TSO, the TSO will correctly copy
> the option into individual segments correctly.
> 
> If, however, you implement this badly - and pass TCP segments as a whole
> to the offload engine, then the offload engine *has no business* splitting
> or coalescing segments.


I can agree with the assessment, that TSO is typically done wrong, and that the API was not properly designed.

Most TSO NICs only deal with "typical" header flags - from my ECN research I know that non-ECT (CE; ECT(0); ECT(1)) IP flags are not necessarily delivered correctly by LRO (only the IP bits of the first segment that was received are usually handed up to the software TCP stack, even when they change; thus ECN information in up to 200 segments may never reach the TCP layer for handling (and recent measurements also indicate that for ECN, the gating issue is not TCP ECN, but the IP ECN flags getting forwarded end-to-end properly...

On the LRO TCP side, any "unexpected" TCP header bits (EDO wouldn't account for this; setting DO to an invalid value might) would typically stop the fastpath processing, and get individual segments delivered - thus the RFC3168 ECN TCP signaling usually works (as ECE and/or CWR bits are set in those segments).


As for a TSO sender: if the NIC driver is broken, the sending TCP can ensure that the hardware doesn't perform invalid splits on segments containing EDO - it has to be provided as a NIC driver workaround, sure; 


Richard Scheffenegger