headers
Stefanos Harhalakis | 1 Oct 2010 11:08
Picon

Re: Early FIN/close for query-response TCP connections like DNS's

On Friday 01 of October 2010, David P. Reed wrote:
>   TCP endpoint stacks are not part of IETF standards.  In particular
> "socket" calls and their meaning are not standardized.

Of course. I don't suggest any change required in any point in the underlying 
stack. Only a suggestion for implementations of DNS/TCP clients.

> I suspect that there might be a problem here in the actual *stacks*
> because to "half close" a connection, one issues a "close" to the
> socket.  After such a command, many operating systems may not expect to
> provide more data on the receive side.

In fact one has to use shutdown() instead of close(). From what I understand, 
close() closes the socket, while shutdown handles the connection leaving the 
socket fd valid.

> I suppose you could signal a half-close without an operating system
> close by some kind of ioctl call (in Linux type OS's).  In OS's like
> Symbian and DOS/Windows, etc., there may be some "control" operation
> that one can call. However it would be decidedly non-standard for the
> client to close when it expects more data.

In linux it works fine. You only have to shutdown() the socket with 
how=SHUT_WR. Here's the tcpdump of  a test where a client sends 10K data and 
receives 10K data while the server receives 10K data, sleeps for 1 second and 
sends 10K data. The client half closes the connection after it finishes 
write()ing:

Connect/Accept:
11:38:57.908427 IP 127.0.0.1.44572 > 127.0.0.1.9996: Flags [SEW], seq
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Touch | 5 Oct 2010 20:25
Picon
Favicon

Call for contribution to middlebox survey

Hi, all,

The following is forwarded from the multipathtcp mailing list.

Joe (list admin)

------

From: Michio Honda <micchie <at> sfc.wide.ad.jp>
Date: October 3, 2010 2:30:57 GMT+03:00
To: Multipath TCP Mailing List <multipathtcp <at> ietf.org>, "tcpm <at> ietf.org" 
<tcpm <at> ietf.org>
Cc: Mark Handley <m.handley <at> cs.ucl.ac.uk>
Subject: [multipathtcp] Call for contribution to middlebox survey

Hi,

We are surveying middleboxes affecting TCP in the Internet, and we'd 
like you to contribute to this work by running 1 python script at your 
available networks, because we want data of as many paths as possible.
This script generates test TCP traffic to a server node, and detects 
various middlebox behavior, for example, it detects how unknown TCP 
options are treated and if sequence number is rewritten.

- Overview of script
This generates test TCP traffic by using raw socket or pcap.
Destinations of the test traffic are port 80, 443 and 34343 on 
vinson3.sfc.wide.ad.jp, which is located in Japan.
The total amount of test traffic is approximately 90 connections (not 
parallel), and each of them uses approximately maximum 2048Byte.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefanos Harhalakis | 14 Oct 2010 11:35
Picon

Re: Early FIN/close for query-response TCP connections like DNS's

On Friday 01 of October 2010, David P. Reed wrote:
>   Stefanos - good point about shutdown.  I had pretty much forgotten it
> existed in Unix stacks, I don't even know if I've had much reason to use
> it...  I checked Symbian and Windows, finding that they do have
> similarly named calls. that support declaring the end of writing and
> sending a FIN.

Thanks for testing that!
Permalink | Reply | 0 comments |
headers
Stefanos Harhalakis | 14 Oct 2010 11:34
Picon

Re: Early FIN/close for query-response TCP connections like DNS's

Hello,

On Wednesday 13 of October 2010, Alfred Hönes wrote:
> Stefanos,
> regarding your question on TCP connection management for DNS, please
> see RFC 5966 (DNS Transport over TCP - Implementation Requirements).

Thanks for the pointer. I just read it. See comments inline:

> For instance, an end-system resolver (or a DNS forwarder, e.g. in an
> access gateway) that is configured with a single recursive resolver,
> to which it will forward all queries, should preferably keep a TCP
> connection open for considerable time, ideally forever.

This should only apply whenever a stub resolver is involved. If it isn't or 
the client API directly contacts the DNS server (like in linux systems without 
nscd running) then it is not possible to use this kind of keep-alived 
connections (no?).

In that case the client may not benefit from an open connection (e.g. when 
running "dig") or it is not aware of using TCP. I believe that this is the 
case of most implementations that use gethostbyname() (or similars) without 
using sethostent(1). Since gethostbyname() will retry using TCP whenever the 
UDP query was truncated and then close the connection, the early FIN would 
work there.

> Unless the server is under serious resource pressure, it should keep
> a TCP connection open for a time span that is comparable to the time
> it would keep the closed connection in TIME-WAIT state.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Gont | 15 Oct 2010 08:51
Picon
Favicon

Re: Early FIN/close for query-response TCP connections like DNS's

On 30/09/2010 05:24 p.m., Stefanos Harhalakis wrote:

>>From what I understand, the FINs are problematic for this kind of traffic so I 
> was wondering: Why not transform this to:
> 
> * Client connects
> * Client queries
> * Client closes
> * Server responds
> * Server closes
> 
> IOW: Since we know that this connection will have a Query and a Response, why 
> not half-close the connection after the query is sent? This requires no 
> modifications to TCP's behavior and will save at least RTT/2 because the 
> server side will not wait for a FIN before closing. (no?)

Are you aiming at reducing state on servers?

If that's the case, one might argue that you still need to handle this
(and any other) sequence gracefully... or else expect that you might be
the subject of DoS attacks....

Thanks,
--

-- 
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Permalink | Reply | 1 comment |
headers
Stefanos Harhalakis | 29 Oct 2010 15:06
Picon

Re: Early FIN/close for query-response TCP connections like DNS's

Hello,

On Friday 15 of October 2010, Fernando Gont wrote:
> On 30/09/2010 05:24 p.m., Stefanos Harhalakis wrote:
> > IOW: Since we know that this connection will have a Query and a Response,
> > why not half-close the connection after the query is sent? This requires
> > no modifications to TCP's behavior and will save at least RTT/2 because
> > the server side will not wait for a FIN before closing. (no?)
> 
> Are you aiming at reducing state on servers?
> 
> If that's the case, one might argue that you still need to handle this
> (and any other) sequence gracefully... or else expect that you might be
> the subject of DoS attacks....

While reading old mails of end2end-interest, I was left with the impression 
that there is concern about the TIME_WAIT state of DNS servers and the port 
allocation period. Having that in mind, I came with the above proposal.

>From what I understand, (when using my proposal) since a DNS client would be 
the first to close the connection, it will have to wait in TIME_WAIT and the 
server will not. In contrast, with the current situation, if a server supports 
persistent connections, it should wait for the client to close the connection 
first, meaning that the DNS server will have to TIME_WAIT.

Early half-closing of a connection is not a violation of TCP and does not 
affect the reliability of the connection. The connections are still closed 
gracefully and there is no possibility of data loss or DoS attacks. 
Furthermore, the proposal does not require any modifications at all in the 
server's implementation and could be implemented with very few changes in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefanos Harhalakis | 29 Oct 2010 15:20
Picon

Re: Early FIN/close for query-response TCP connections like DNS's

Hello,

On Thursday 14 of October 2010, Alfred Hönes wrote:
> On Thu Oct 14 02:34:15 PDT 2010, Stefanos Harhalakis wrote:
> > On Wednesday 13 of October 2010, Alfred Hönes wrote:
> >> For instance, an end-system resolver (or a DNS forwarder, e.g. in an
> >> access gateway) that is configured with a single recursive resolver,
> >> to which it will forward all queries, should preferably keep a TCP
> >> connection open for considerable time, ideally forever.
> > 
> > This should only apply whenever a stub resolver is involved. If it
> > isn't or the client API directly contacts the DNS server (like in
> > linux systems without  nscd running) then it is not possible to use
> > this kind of keep-alived connections (no?).
> 
> Most clients -- be they application-based or host-based -- will likely
> talk to a *single* recursive resolver all the time (the one they have
> been configured with via DHCP or PPP[oE], or via static configuration),
> and not to the different authoritative resolvers directly;
> debugging tools like dig are an exception, of course.

Indeed, but the persistent connection may only be used when there is a stub 
resolver running at client-side (For example, you cannot share a TCP 
connection to the DNS server between two clients like Firefox and IE) (this is 
the host-based client you're referring).

> > In that case the client may not benefit from an open connection (e.g.
> > when running "dig") or it is not aware of using TCP.  I believe that
> > this is the case of most implementations that use gethostbyname() (or
> > similars) without using sethostent(1).  Since gethostbyname() will
(Continue reading)

Permalink | Reply | 0 comments |

Gmane