From: Rick Jones <rick.jones2@hp.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Glen Turner <gdt@gdt.id.au>, netdev@vger.kernel.org
Subject: Re: UDP path MTU discovery
Date: Mon, 29 Mar 2010 13:25:20 -0700 [thread overview]
Message-ID: <4BB10CB0.5090702@hp.com> (raw)
In-Reply-To: <20100329201431.GH20695@one.firstfloor.org>
Andi Kleen wrote:
> On Mon, Mar 29, 2010 at 10:01:42AM -0700, Rick Jones wrote:
>>But which of the last N datagrams sent by the application should be
>>retained for retransmission? It could be scores if not hundreds of
>>datagrams depending on the behaviour of the application and the latency to
>>the narrow part of the network.
>
>
> Yes, if there's a large window you lose. I guess it would make protocols
> like DHCP work at least ("transactional UDP" as the original poster called it)
>
> I don't know if it would fix enough applications to be worth
> implementing. The only way to find out would be to try I guess.
> I don't have any better ideas.
I don't think there are any good solutions that do not require either
application involvement, or a modification to IPv6.
How about allowing an application to request that (copies of) ICMP(v6) messages
be made available through the socket? In that way, the application, which
ostensibly already has to be keeping track of its sends for its own nefarious
retransmission porpoises can receive the "signal" just like TCP does and perhaps
there will be enough in the ICMPv6 message for the application to know which
message(s) need to be retransmitted.
rick jones
next prev parent reply other threads:[~2010-03-29 20:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 0:02 UDP path MTU discovery Glen Turner
2010-03-26 0:53 ` Rick Jones
2010-03-26 3:26 ` David Miller
2010-03-26 17:48 ` Rick Jones
2010-03-31 23:42 ` Glen Turner
2010-03-31 23:51 ` Hagen Paul Pfeifer
2010-04-01 0:06 ` Rick Jones
2010-03-26 3:24 ` David Miller
2010-03-28 8:41 ` Andi Kleen
2010-03-31 23:57 ` Glen Turner
2010-04-01 0:57 ` Andi Kleen
2010-03-28 8:50 ` Andi Kleen
2010-03-29 17:01 ` Rick Jones
2010-03-29 20:14 ` Andi Kleen
2010-03-29 20:25 ` Rick Jones [this message]
2010-03-29 20:50 ` Edgar E. Iglesias
2010-03-29 21:01 ` Rick Jones
2010-03-29 21:29 ` Eric Dumazet
2010-03-29 23:38 ` Templin, Fred L
2010-03-30 5:20 ` Andi Kleen
2010-03-30 6:06 ` Eric Dumazet
2010-03-30 6:16 ` Andi Kleen
2010-03-30 6:17 ` UDP path MTU discovery II Andi Kleen
2010-03-30 6:16 ` UDP path MTU discovery Edgar E. Iglesias
2010-03-30 6:19 ` Andi Kleen
2010-03-30 8:20 ` Edgar E. Iglesias
2010-03-30 14:12 ` Andi Kleen
2010-03-30 22:04 ` Edgar E. Iglesias
2010-03-30 15:58 ` Templin, Fred L
2010-03-30 16:06 ` Andi Kleen
2010-03-31 23:43 ` Glen Turner
2010-04-01 0:55 ` Andi Kleen
2010-04-02 5:41 ` Glen Turner
2010-04-04 10:25 ` Andi Kleen
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=4BB10CB0.5090702@hp.com \
--to=rick.jones2@hp.com \
--cc=andi@firstfloor.org \
--cc=gdt@gdt.id.au \
--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).