Re: [tcpm] Faster application handshakes with SYN/ACK payloads

On Tue, Jul 15, 2008 at 11:53 PM, Michael Scharf
<michael.scharf@ikr.uni-stuttgart.de> wrote:
> sorry for asking once again "stupid" questions: Wouldn't it be a
> simple solution if the server just sent the data in a normal packet
> immediately after the SYN/ACK?

That's a very interesting idea; I hadn't considered it.

The pros would be that one could imagine that the active open host
wouldn't need any changes to support it. Let's consider what could go
wrong:

Packet loss: shouldn't be an issue. If the SYNACK is lost, the packet
with a payload would, at worst, get ignored. Possibly some stacks
would enqueue it.
Reordering: again, should be fine. Since the data packet is affecting
the sequence numbers it would get retransmitted if it was dropped
because it arrived early.

However, application level protocols probably need to change in order
to take advantage of early passive-open data transmission. Either
because they weren't designed with that in mind or because they need
to be a lot more frugal with their bits to fit within the 64-byte
limit. So the option in the SYN would still be needed, and that means
there's an issue of consistency. Both sides need to know if early-data
is in play because it affects the application level. Consider

AO: active open host
PO: passive open host

1. AO: A SYN is sent with SYNPACK Payload Permitted
2. PO: A SYNACK reply is sent and a data packet is sent
3. AO: A timeout occurs and the SYN is retransmitted without the
permitted bit. Although I don't think middleware dropping the unknown
option is going to be too much of a problem (see citations in the
draft), it's good if hosts have the option of doing this
4. AO: The SYNACK packet (from step 2) arrives. ACK is sent
5. AO: The data packet (from step 2) arrives and is enqueued.
5. PO: The second SYN causes another SYNACK (which will be ignored by AO)
6: PO: The ACK arrives

Now, neither side believe that an extra data packet was in play (AO
because it timed out and transmitted without the permitted bit in 3
and PO because it got a SYN without the bit in 5). However, the data
reaches the application level.

This means that we have to mark the data packet in some way (probably
an option) so that AO can drop it at step 5. Alternatively we could
require that, if the AO host wishes to back off from sending the
permitted bit, it has to start a whole new connection.

Another con would be the, minor, additional SYN flood problems - a SYN
can now elicit two packets and an additional 30 (or so) bytes from a
host.

So I think the balance comes out against, but it was very much worth
the consideration.

Thanks

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm