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

["Sergio Freire" <[e-mail]>]

Hi Adam et all,
I have been on vacations but I have the thread of emails concerning this
subject.
We would like also to propose something about this as Joe Touch mentioned
earlier.
Me and Andre Zúquete have published a paper for proposing a TCP-layer name
service.
http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire.pdf

In this work we "propose" the use of data in the SYN/SYN+ACK segments.
We intend to generalize this and also to go forward on this matter.
I have to see carefully the thread of your earlier discussions and your
draft as of the current version, so we can see if we're going in the same or
in opposite/alternative directions.
Meanwhile, if you can take a look at our work, it would be great for further
discussion (regarding the way of extending tcp options and not the name
service itself).

Note: I think this is an important subject and I'm glad we're pushing this
forward, even if we propose alternate ways for this. Please give me some
days so I can synch.

Regards,
Sergio Freire


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Adam
Langley
Sent: segunda-feira, 11 de Agosto de 2008 18:35
To: [e-mail]
Subject: [tcpm] SYN/ACK Payloads, draft 01

The comments on SYNACK Payloads[1] seem to have died down, so I'd like
to see how people are feeling about it.

Just to be clear; I'm seeking to publish this as experimental in order
to get an option number assigned to conduct more widespread tests.

I thought that I would dig out a couple of the points that I believe
Joe Touch was still unsure about after the last thread. I don't wish
to misrepresent anyone, but it is a long thread to dig through: thanks
to Joe for being so generous with his time in giving feedback.

> I appreciate the
> idea of optimizing TCP, but there are so many other places where RTTs
> are not under your control, and so many RTTs in a connection, that
> removing (or adding) a single one anywhere seems in the noise."

Many Google users are now using search bars to submit queries. Thus
they type into a text field in the browser, hit enter and the browser
makes a connection, sends the query encoded in a GET and displays the
result. This is one example of a situation where the connection
latency isn't amortised. There are many others, but obviously, this is
the example that usually dominates my thinking. And, in this
situation, it turns out that every 10ms makes a difference.

I might be wrong here. This might be an overcomplex solution. But I
think only time will tell, which is why I wish to have it published as
an experimental spec. If, in a couple of years, it doesn't work the
option number can be released, ready for the next guy.

> Using a transport signal to change the application protocol seems
> very strange to me. Other's can comment on that.

It is strange, I agree. My usual test about such things is if I get an
"ick" reaction and, in this case, I don't. Although, that might just
be me.

Two reasonable questions arise:

"Where will this stop?"  - obviously, the TCP option space shouldn't
be a repository for application data. In this case, at least, the
option is advertising a certain minimum capability of the TCP stack,
as defined in the draft. Also, I'll claim that this is the last such
need in this area:

The SYNACK payload sizes is a decision for the server (within the
advertised window). No more client options could be needed to
advertise support for larger ones.

Since the SYNACK payload is (nearly) constant, and TCP stacks are not
going to differ sufficiently to change this in the next 20 years,
applications don't gain anything else by stuffing anything more in the
SYN option space.

So I don't think this sets an unreasonable precedent.


Thanks all,

[1] http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt



AGL

-- 
Adam Langley [e-mail] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm

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