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

[John Leslie <[e-mail]>]

Joe Touch <[e-mail]> wrote:
> 
> Some additional information below about "another trick" I proposed, 
> inspired by Bob's dual-SYN mechanism, courtesy a few long discussions 
> today with Ted Faber.

   This _is- as interesting idea...

> I'll be glad to offer this as a potential solution in the doc.

   I'd _much_ rather this be detailed in a separate document. The edo
proposal is reasonably easy to understand, while this contains multiple
layers of complexity.

   I _don't_ claim to understand it all -- if we try to publish this
in an RFC, a _lot_ of work will be needed to clarify everything...

> On 5/30/2014 1:34 PM, Joe Touch wrote:
> ...
>> Here's another trick that might clean up the above a little:
> 
> FWIW, I had explained it below as being based on sending out-of-window 
> data; Ted pointed out that I had been assuming that the FBP ACK bit 
> wasn't set - which means the sequence number might be more usefully 
> matched to that of the SYN.

   I see you now give the "second" packet the same sequence number.
I feel a need to describe the FBP more exactly. I'm guessing it's the
same port pair (but I very much dislike guessing!). Obviously it's
the same IP-address pair (but can we really depend upon middleboxes
to translate both packets the same?). I won't venture a guess as to
whether it has the SYN bit set (but thanks for saying the ACK bit
is clear). Et cetera...

> See below...
> 
>>     aso - after SYN option

   This is an option within the Options field of the first SYN, right?

> 		length = 2 (just a flag)
> 		length = 3 (or 4) indicating the length of the
> 			FBP expected

   What does length==2 tell us about the FBP?

>>     FBP - front bumper packet (best I could do on names today)
>>         a packet
> 		ISN = same as the associated SYN
> 		ACK = cleared (i.e., a data packet NOT part of
> 		synchronized connection - see why that's useful below)

   Does this have SYN set?

   How does the sender of the FBP learn what the receiver of the FBP
took it to mean? (Assuming, of course, it was received at all...)

>>     new endpoint sends:

   What's a "new endpoint"?

>>         SYN + aso + fix_opt
>>         FBP + aso + extra_opt
> 
> 		extra_opt in the data field
> 		total length < min MTU (576 for IPv4, 1280 for IPv6)
> 		again ACK bit is zero

   I get very nervous about using the data field before the handshake
is complete.

>>             legacy endpoint sends back one connections:
>>                 SYN-ACK + fix_opt

   Presumably the legacy endpoint ignores the FBP... but what happens
if only the FBP arrives (the initial SYN being lost or mangled by a
middlebox)?

>>                 if seg arrives before SYN,

   Am I supposed to assume "seg" here means FBP?

> 			it is silently dropped, because
> 			the ACK bit is clear (this is
> 			explicit in RFC793)
> 
> >                 if seg arrives after SYN,
> 
> 			it is silently dropped, because
> 			the ACK bit is clear (this is also
> 			explicit in RFC793)
>>             ----
>>
>>             new endpoint sends back one connection:
>>
>>                 SYN-ACK + options + ....
>>
>>             a) if FBP arrives before SYN,
> 
> 			it can be silently dropped, but
> 			it's probably useful for new endpoints
> 			to hold onto these (without action)
> 			for a while; they can be silently
> 			discarded if there are too many
> 			(which will just result in a
> 			retransmission and an extra RTT)

   Your hands are waving...

>>             b) if FPB arrives with the SYN, they can be
>>             processed together
>>
>>                 the SYN-ACK can include responses to
>>                 the extra_opts in addition to the
>>                 fix_opts, and says "FBP received"

   How would it say "FBP received"?

>>             c) if FPB arrives after the SYN:
>>
>>                 SYN-ACK proceeds, but sends
>>                 back "wait for option response".

   How would it send that?

>>                 at this point, the source re-sends FBP
>>                 until an ACK is received that indicates
>>                 "FBP received", or times-out as with
>>                 any connection that doesn't finish TWHS

   This sounds like the timeout wouldn't be rare -- a middlebox might
pretty automatically drop the FBP, depending...

>>             I'm still thinking as to whether the ACK number
>>             might indicate whether FBP has been received,

   That sounds strange...

> There are a few ways to handle this, but IMO the best is to have:
> 
> 		SYN-ACK aso with length=2 means "waiting for FBP"
> 
> 		SYN-ACK aso with length=3 (or 4) could mean
> 		"got the FBP", or might even indicate how
> 		many bytes the FBP extension contained

   That's limiting...

> Note - the SYN-ACK and all subsequent segments can assume that aso == 
> edo, i.e., they can use the same EDO as spec'd in version 01 of this draft.

   Please! No!

   (Option numbers aren't that scarce.)

--
John Leslie <[e-mail]>