Re: [hackathon] [Ext] IETF 118 Hackathon: Are long-lived TCP sessions a problem for (DNS) statistics?

Hi,

Thanks for jumping in!

We are well aware of long term TCP sessions that carry other protocol traffic. However, for DNS over TCP, at least at some the root-server instance traffic DITL data, it seems that the bulk of TCP sessions are short lived, where the lifetime lasts mostly a single query/response pair. We even see multiple (parallel) TCP sessions occur from a single client to a single server. 

Some tools that monitor DNS traffic, that include traffic over TCP derived from 5 minute PCAP files, need to observe a syn/ack first before including DNS traffic within that session. Additionally, some tools do not expect a second query in the same session. This leads to a potential under-reporting of DNS-over-TCP traffic. We’d like to analyse a bit more DITL traffic to look for TCP sessions that lasts longer than a query/response exchange, and see for how long it lasts, etc. 

We could then feed that traffic into monitoring tools to look for accurate reporting. 

Hope this helps to understand the premise for the proposed hackathon work.

Warmly,

Roy Arends

> On 1 Nov 2023, at 15:27, John Scudder <jgs=40juniper.net@dmarc.ietf.org> wrote:
> 
> And for that matter, BGP runs over TCP and it’s not unusual to see BGP sessions that are up for months. I wouldn’t be surprised if there were ones that stayed up for more than a year. I didn’t reply earlier because the question seemed to be specific to DNS/TCP, but since someone else jumped first… :-)
> 
> I regret to say I don’t have hard data to offer, just anecdote. 
> 
> —John
> 
>> On Oct 6, 2023, at 11:56 AM, Warren Kumari <warren@kumari.net> wrote:
>> 
>> 
>> On Fri, Oct 06, 2023 at 4:30 AM, <rs.ietf@gmx.at> wrote:
>> I don't have data ready to share, but i want to point out that in the storage space (NFS; SMB; iSCSI; NVMe/TCP; iWARP) - which is not necessarily on the public internet though, it is the norm rather then the exception to have TCP sessions being active for days and weeks at a time - typcially only reestablished after some more or less severe disruption (hosts rebooting, ports failing, excessive packet discards...).
>> 
>> 
>> 
>> I think that this is also true for a bunch of VPN / tunneling technologies. 
>> 
>> For example, I've had a number of enterprise site-to-site "SSL Tunnels" which have been up for many many months, as well as a bunch of SSH tunnels (and just sessions) for similar times. In fact, I recently stumbled across an SSH connection to a terminal server which had been up for a few years — someone had SSHed from a console server to a termserver, and then disconnected, leaving the session up indefinitely. 
>> 
>> W
>> 
>> 
>> 
>> I can not comment on DNS/TCP sessions though. 
>> 
>> Best regards, 
>> Richard
>> 
>> Am 06.10.2023 um 09:27 schrieb Jerry Lundström: 
>> 
>> Hi all, 
>> 
>> Some tools uses packet capturing to do statistics for DNS and some of them needs to see the beginning of the TCP sessions. If resolver systems out there start keeping TCP session against authorities open for a very long time (days or weeks) then it might become a problem for these tools. 
>> 
>> We would like to look at two things; 
>> 1) First to poke at data to see if there are very long-lived TCP sessions out there today, or not(!) which is equally interesting to know. 
>> 2) Second to survey DNS statistics tools out there to see how they handle long-lived TCP sessions to understand how wide a problem this might be, if any. And maybe fix some of them if issues are spotted when doing this.
>> 
>> Sounds interesting? Do you have data to poke at? Hope to see you at the hackathon then! :) 
>> 
>> Cheers, 
>> Jerry Lundström & Roy Arends
>> 
>> _______________________________________________ 
>> hackathon mailing list 
>> hackathon@ietf.org 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hackathon__;!!PtGJab4!_o8pfsPaVtEEUhH2sPdKH0avw6EFzPZbyuztEVDO8XodqCqHOFRdQBUEZPN3Tzl9tQ7zm9Wlyec-0LG7Xe6I5td-La9273RwbiBS6A$ [ietf[.]org] 
>> Unsubscribe: mailto:hackathon-request@ietf.org?subject=unsubscribe
>> 
>> _______________________________________________ 
>> hackathon mailing list 
>> hackathon@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hackathon__;!!PtGJab4!_o8pfsPaVtEEUhH2sPdKH0avw6EFzPZbyuztEVDO8XodqCqHOFRdQBUEZPN3Tzl9tQ7zm9Wlyec-0LG7Xe6I5td-La9273RwbiBS6A$ [ietf[.]org] 
>> Unsubscribe: mailto:hackathon-request@ietf.org?subject=unsubscribe
>> 
>> 
>> _______________________________________________
>> hackathon mailing list
>> hackathon@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hackathon__;!!NEt6yMaO-gk!C5cszFscM6tI6kNzCMFJW1rcvh82rEQl7j3LVB-rfHmJJP3x7tUqWs5hshga0Pie03Z6-fSDa-OK$
>> Unsubscribe: mailto:hackathon-request@ietf.org?subject=unsubscribe
> 
> _______________________________________________
> hackathon mailing list
> hackathon@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hackathon__;!!PtGJab4!_o8pfsPaVtEEUhH2sPdKH0avw6EFzPZbyuztEVDO8XodqCqHOFRdQBUEZPN3Tzl9tQ7zm9Wlyec-0LG7Xe6I5td-La9273RwbiBS6A$ [ietf[.]org]
> Unsubscribe: mailto:hackathon-request@ietf.org?subject=unsubscribe

Re: [hackathon] [Ext] IETF 118 Hackathon: Are long-lived TCP sessions a problem for (DNS) statistics?

Attachment: smime.p7s