Re: [Tsvwg] "DO IT RIGHT", or "DON'T DO IT AT ALL"

[Randall Stewart <[e-mail]>]

Joe:

Just a comment in support of something you said below..

Joe Touch wrote:
> Williams, Jim wrote:
> 
>> The subject under discussion here is transforming
>> TCP into a record aligned transport to allow receivers
>> to do some level of ULP processing prior reassembly
>> of the TCP stream.  The specific goal is to enable
>> an RDDP protocol to directly place incoming
>> data even if TCP segments arrive out of order.
>>
>> At least two drafts have been submitted which
>> propose mechanisms:
>>
>>      draft-ietf-tsvwg-tcp-ulp-frame-01.txt [tuf] (expired)
>> and
>>      draft-culley-iwarp-mpa-00.txt [mpa]
>>
>> In Atlanta I argued the case for "DON'T DO IT AT ALL".
>> The case being that TCP is a stream protocol and should
>> not be used otherwise.  SCTP is a record protocol and
>> should be used when a record protocol is needed.
>> And that "fixing" TCP rather than switching to SCTP
>> is the wrong architectural direction.
>>
>> However in that aftermath of Atlanta I fear that
>> my argument is losing within the RDDP group, so I would
>> like to at least explore the alternative.
> 
> 
> I'd say "DON'T BOTHER AT ALL". Here's why:
> 
>     1- anything that really does something useful
>     is going to require EITHER a change to
>     TCP semantics (the SEND/RECEIVE etc. API) OR
>     to default to current semantics
> 
>     2- changing semantics of the default case is
>     simply not an option. There's too many
>     critical (e.g., financial, commerce, etc.)
>     systems that are based on existing semantics.
>     We don't know what will break or when, and
>     setting up a wide-scale gamble simply isn't
>     appropriate.
> 
>     3- changing semantics of a non-default case
>     begs the question: why not just compile in
>     a different protocol? SCTP, DCP, or write
>     your own on UDP.
>     
>     The answer I've been hearing is "we need
>     it now, and need it to work for legacy apps".
>     But that means you also need legacy semantics,
>     which means #2 applies.
> 
> Finally, I'd appreciate hearing a discussion of why this should all work 
> that doesn't include some glaring errors. E.g., at the last meeting we 
> all heard about how TCP with Nagle off (NODELAY) sends packets that 
> match what the send calls issue. That simply isn't the case, never was, 
> and cannot be assumed regardless. E.g., how do you know the path MTU 
> didn't change between when you checked it/issued the write and when the 
> packet is emitted?
> 

One of the companies I worked for in the past made the above assumption.
All was well and it worked as planned until they were under
tremendous load.. then guess what.. there aligned assumption blew
up .. and so did the application :-0.. in the after-math record
markers were quickly inserted...

R



> Many of the other debates about these other protocols ignore the fact 
> that the TCP spec is defined in terms of two interfaces - one below (the 
> packets) and one above (the API, in terms of generic 
> SEND/RECV/OPEN/CLOSE etc.) The API appears to be ignored in most cases.
> 
> ...
> 
>> Both [tuf] and [mpa] state
>> that the receiver might or might not get record aligned
>> segments, and they both add another layer of protocol
>> processing to allow the receiver to determine whether
>> the alignment attempt was or was not successful.  They
>> both require that the receiver to support the dual complexity of 
>> handling both aligned and unaligned
>> segments on a given connection.
>>
>> To me, this seems to have the type of undesirable complexity often 
>> associated with ill advised, ad hoc
>> solutions.  I would encourage that some thought
>> be given to a more cleanly architected solutions
>> even if the down side is greater impact on TCP
>> bahavior.
> 
> 
> How about realizing that: these are TWO different transport protocols, 
> and deserve two different protocol numbers?
> 
>> There are two fundamental problems with guaranteeing
>> record alignment to the receiver.
>>
>>   1.  How can the sender always align.
>>
>>   2.  How can middle-boxes be prevented from
>>       re-segmenting the TCP stream.
>>
>> With respect to 1., both drafts state that alignment
>> will usually be done, but list a number of exception
>> cases under which the sender will not attempt to align. 
>> I would propose as part of "doing it right" that
>> a sender which agrees to align must ALWAYS align
>> records with TCP segments.  I will not attempt
>> now to list here all the implication of this, but the summary is that 
>> this will require
>> small but substantive changes to TCP
>> sender behavior, and that these changes, if done
>> right, will not break interoperability with existing implementations.  
>> (However this is
>> a tricky area, and until the work is done, it is not possible to be 
>> sure.)
>>
>> With respect to 2., I would propose that senders
>> that agree to align should announce this intention
>> by adding a newly defined RECORD_ALIGNED TCP option
>> to the SYN segments used to set up the connection.
> 
> 
> Good luck on that. Middleboxes exist because the middlebox owners want 
> them to, and often don't want to be seen. They already violate the E2E 
> argument, and many aspects of the core specifications of the Internet 
> (1122,1123, etc.).
> 
> Now you expect them to respect a flag you put in the header. Why do you 
> expect them to respect a new spec, when the don't respect the existing 
> ones?
> 
> ...
> 
>> However, in practice this will not be a big enough
>> problem that it should drive protocol design in a
>> major way.  Middle boxes that re-segment, and also
>> send a TCP option agreeing not to re-segment
>> are engaging in aberrant and erroneous behavior,
>> and will cause connections to quickly close in error.
> 
> 
> Yeah, right. Or the will cause the applications to break, and not work 
> at all, as NATs often do. Then what?
> 
>> The result is either they will be fixed, or
>> the affected receivers will be configured to
>> not assume alignment (ignore incoming RECORD_ALIGNED
>> options).
> 
> 
> How? When you're at a meeting and need to get to your email, then what? 
> Did the NAT boxes that hit you last time magically disappear, or did 
> your end or your servers' get reconfigured to work?
> 
> This is not a useful path to spend further energy, IMO.
> 
> Joe
> 
> 
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> 


-- 
Randall R. Stewart
[e-mail] 815-342-5222 (cell phone)

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg