Re: [tcpm] SYN/ACK Payloads, draft 01

["Caitlin Bestler" <Caitlin.Bestler at neterion.com>]

Adam Langley wrote:

> 
> > and 2) Designing a feature that deliberately throws away some
> > of the TCP payload stream seems contrary to the whole concept
> > of a reliable transport.
> 
> Here you are thinking about including SYN/ACK payloads when many
> clients will ignore them? It does have some inefficiency problems,
> I'll agree. However, I mostly expect that SYN/ACK payloads will only
> be returned to clients which have explicitly requested it with an
> option. There are certainly some server-speaks-first protocols (like
> SMTP) which could oppitunistically use SYN/ACK payloads. Then the
> inefficiency decision has to be made on a per application basis,
> probably a config option somewhere.
> 

My reservation is entirely theoretical.

The "overhead" of 64 data bytes on a SYN/ACK frame that is being
sent anyway is very slight or even zero, depending on exactly
what forms of intermediate queuing are in use.

The real concern would be if applications that did not use the
special sockopts were to have this special payload automatically
discarded by the stack.

Automatic discarding of payload, no matter how efficient, just
strikes me as contrary to the definition of what it means to
be a "reliable transport" service.

And experience has taught me that when something looks really
bad from a "purely theoretical" viewpoint it merely means that
I have not yet identified the specific case where it *will*
cause problems. So at the minimum I like to come up with
a strong reason why something is intrinsically safe, not
just "So far, I haven't thought of how it goes wrong."

_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www.ietf.org/mailman/listinfo/tcpm