From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Kristian Evensen <kristian.evensen@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] tcp: Add TCP_FREEZE socket option
Date: Wed, 22 Oct 2014 21:50:14 +0200 [thread overview]
Message-ID: <CAPh34mechU=aUS422OBFhHUt68Nk2PZBsMiLPw8eLwS_4PnRtw@mail.gmail.com> (raw)
In-Reply-To: <CAKfDRXgARYe3hw3vgpgup1X4bNjH0cpwYOfKUZK51HcOf2jeJA@mail.gmail.com>
On 22 October 2014 19:08, Kristian Evensen <kristian.evensen@gmail.com> wrote:
> Another approach I designed was to have a separate TCP Freeze module
> and trigger the freeze/unfreeze through genetlink-messages. A user
> space application will be responsible for monitoring the devices and
> decide when to trigger the ZWAs. Would a design like that be
> acceptable?
At least better. But what userspace daemon would configure this?
Likely NetworkManager and friends. But at what conditions?
- When the WIFI signal strength is below some threshold?
- When switched to another AP?
- When switched from 802.11 to 802.3
- ...
In a NATed scenario there is no gain because IP addreses change and
the connection is lost anyway. For the signal strength thing there
might be an advantage but it has costs:
a) how long did you freeze the connection? What if NetworkManager
stops? The connection hang \infty
b) is it not better to inform the upper layer - the application - that
something happen with the link?
I mean when the application experience disruptions, the application
can decide what it do: reconnect, reconnect and resend or inform the
user. This possibility is now lost/hidden. Maybe it is no problem -
maybe it is for some applications.
I have no fundamental problems with TCP Freeze, but what is missing is
a complete story line. The use cases where it makes sense and if it is
save.
Do you have considered to bring this to the IETF (TCPM WG)?
Hagen
next prev parent reply other threads:[~2014-10-22 19:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 15:36 [PATCH net-next] tcp: Add TCP_FREEZE socket option Kristian Evensen
2014-10-22 15:54 ` Eric Dumazet
2014-10-22 16:10 ` Kristian Evensen
2014-10-22 16:14 ` David Miller
2014-10-22 17:08 ` Kristian Evensen
2014-10-22 19:50 ` Hagen Paul Pfeifer [this message]
2014-10-22 20:33 ` Kristian Evensen
2014-10-24 14:58 ` Yuchung Cheng
2014-10-24 16:26 ` Hagen Paul Pfeifer
2014-10-25 21:29 ` Kristian Evensen
2014-10-25 21:21 ` Kristian Evensen
2014-10-22 16:56 ` Cong Wang
2014-10-22 17:11 ` Kristian Evensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPh34mechU=aUS422OBFhHUt68Nk2PZBsMiLPw8eLwS_4PnRtw@mail.gmail.com' \
--to=hagen@jauu.net \
--cc=davem@davemloft.net \
--cc=kristian.evensen@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).