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

[Joe Touch <[e-mail]>]

On 5/30/2014 6:46 PM, John Leslie wrote:
> 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...

Sure...

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

Yes.

> I feel a need to describe the FBP more exactly.

Of course.

> I'm guessing it's the
> same port pair (but I very much dislike guessing!).

Oh, yes - that's the way it ensures fate-sharing with the SYN.

> Obviously it's
> the same IP-address pair

Yes.

> (but can we really depend upon middleboxes
> to translate both packets the same?).

If the FBP comes after the SYN, yes. If not, the FBP will be dropped, 
and retransmitted when the SYN-ACK indicates the FBP hasn't been 
received (for upgraded servers).

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

It can't have the SYN bit - that would be two SYNs to the same place, 
and if they have different options that'd be confusing for legacy 
servers. If they had the same options, there'd be no increase in space - 
it's not possible to use the data field of a SYN for options because 
legacy hosts will interpret that as user data.

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

Here's more specifically what I was thinking:

	Length = 2 (1 byte), Kind = fpb-option-codepoint (1 byte)

or

	Length = 3, Kind = fbp-option-codepoint, fbp-length (1 byte)

Length == 4 just means a longer fbp-length field, or maybe it means:

	Length, Kind, Flags, FBP-length
		(you'll see below where the flags might come in)

Length == 2 just means there's no fbp-length field. That could mean that 
the length of the FBP should be determined from the FBP packet itself 
(using fbp-length operates as a double-check that the FBP packet 
matches); alternately, it could mean that there's no FBP - i.e., that 
this is just the EDO that extends non-SYN packets.

Alternately, we could use different option codepoints for FBP and EDO, 
in which case the FBP option just means "FBP packet should be expected".

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

No. that would be a second SYN, which causes load problems for legacy 
servers.

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

The ACK that comes back, either in the SYN-ACK (if the FBP has been 
received) or a second ACK after that will have the response to the FBP 
options.

>>>      new endpoint sends:
>
>     What's a "new endpoint"?

An upgraded one, i.e., one that supports this new option...

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

It's safe - as per RFC793. This packet is outside the connection because 
the ACK isn't set. That's effectively saying "this packet is for the 
unsynchronized state". RFC793 says all such packets get silently dropped 
(we're talking about a packet with ACK clear, and NO other control flags 
set - no SYN, no RST, no FIN).

>>>              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)?

They ignore it at all times, except if received in CLOSED at which point 
they send a RST (just like receiving any other packet in that state).

If the SYN is lost, the same thing happens as any time the SYN is lost - 
the client resends the SYN after a timeout, and after some number of 
failed timeouts it gives up.

Upgraded endpoints might keep FBPs for a short time in the hope of 
getting a matching SYN, but if they don't or discard it before it comes, 
the client will resend it when the SYN-ACK indicates its missing.

>>>                  if seg arrives before SYN,
>
>     Am I supposed to assume "seg" here means FBP?

Sorry - typed too fast. Yes, here and throughout the rest...

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

Not that hard. Keeping a cache of recently received FBPs is a simple 
thing to do, and the mechanism is robust to that cache either not 
existing or being small.

>>>              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"?

I thought of a few ways - they all end up being equivalent in spirit to 
a flag in an option field in the SYN-ACK, so let's say it's that for now:

	set FBP-received flag in the aso option

>>>              c) if FPB arrives after the SYN:
>>>
>>>                  SYN-ACK proceeds, but sends
>>>                  back "wait for option response".
>
>     How would it send that?

The FBP-received flag in the SYN-ACK aso option isn't set.

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

If the FBP comes before the SYN, yes. If not, it shouldn't AFAICT.

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

Yeah - nevermind that.

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

I don't see why (FBP can indicate 32-bit words, just like the current 
Data Offset field, which means 255 = 1020 bytes of option space in the 
FBP -- note that this is all contained in the data portion of the FBP 
segment).

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

See above. We could say:
	
	EDO length = 0 in a SYN means no FBP
	EDO length = N in a SYN means FBP with length N

But let's not get hung on that detail either, IMO.

Joe