On July 9th, Carsten Bormann wrote, in part:
>>> But for one problem: adaptation layer fragmentation is
>>> *transparent*, so there is no way for an application
>>> to do the equivalent of PMTUD to avoid/minimize adaptation
>>> layer fragmentation.
>> On 10/07/2013 05:28, RJ Atkinson wrote:
>> G
Doug,
Let's see if we can find some common ground.
Assume that the IETF is considering a new protocol that doesn't run over TCP.
In order to deal with MTU issues, the new protocol must do one of the following:
a) implement PLMTUD or PMTUD
b) restrict itself to sending PDUs so small that when t
Hi,
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Carsten Bormann
> Sent: Tuesday, July 09, 2013 3:08 PM
> To: Manfredi, Albert E
> Cc: ipv6@ietf.org List
> Subject: Re: Meta-issues: On the deprecation of the fragmentation
> function
>
>
> First is, the change of MTU was not one of 576 to 1280.
I think he was talking about changing the minMTU of Steve Deering's Simple IP
from 576 first into the mistaken 1500 and then into 1280 in the process of
turning it into IPv6.
http://tools.ietf.org/html/draft-deering-sip-00
(BTW, is that p
On Jul 9, 2013, at 22:50, Brian E Carpenter wrote:
> On 10/07/2013 05:28, RJ Atkinson wrote:
> ...
>>> But for one problem: adaptation layer fragmentation is
>>> *transparent*, so there is no way for an application
>>> to do the equivalent of PMTUD to avoid/minimize adaptation
>>> layer fragmenta
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian
> E Carpenter
> On 10/07/2013 05:28, RJ Atkinson wrote:
> ...
> >> But for one problem: adaptation layer fragmentation is
> >> *transparent*, so there is no way for an application
> >> to do the equivalent of PMTUD to
On 10/07/2013 05:28, RJ Atkinson wrote:
...
>> But for one problem: adaptation layer fragmentation is
>> *transparent*, so there is no way for an application
>> to do the equivalent of PMTUD to avoid/minimize adaptation
>> layer fragmentation.
>
> Good point.
And you can't get round it. The decis
Hi,
Going back to our discussions from last week, here is a draft that
captures the proposed uses of fragmentation for tunneling and other
purposes. It is called: "Fragmentation Revisited", and it offers an
approach to limited use of fragmentation in a way that can begin to
remove all barriers to
On 07/09/2013 11:12 AM, Ronald Bonica wrote:
Doug,
It might be interesting to revisit what we mean by deprecating IPv6
fragmentation
It means that the IETF will not approve any new protocols that rely upon IPv6
fragmentation. Nothing more, nothing less.
Thanks for clarifying. FWIW, I un
Doug,
It might be interesting to revisit what we mean by deprecating IPv6
fragmentation
It means that the IETF will not approve any new protocols that rely upon IPv6
fragmentation. Nothing more, nothing less.
Old protocols will continue to emit IPv6 fragments. In order to achieve
backward
All,
I support the ideas expressed in this draft.
In the early part of this century, while working for an
equipment supplier that designed their own packet processing
chips, I was involved with the design of a packet processing
chipset that could handle (even small IP packets) at line rate
on 10
I stated it a while back, but now that folks seem to be coming around I
thought it might be worthwhile to restate that I agree that deprecating
fragmentation is a bad idea. My part of this elephant is that we need
fragmentation/PMTUD/Window Scaling to work reliably as we look toward
future netw
> On Jul 9, 2013, at 17:02, RJ Atkinson wrote:
>> The IPv6 concept of adding a special link-specific
>> fragmentation/reassembly protocol layer has never been
>> practical.
My comment (above) was in the context of the kinds of
low-bandwidth links with smaller MTU sizes that I was
discussing,
On Jul 9, 2013, at 17:02, RJ Atkinson wrote:
> The IPv6 concept of adding a special link-specific
> fragmentation/reassembly protocol layer has never been
> practical.
For 6LoWPAN, we did (we had to). And it works well enough.
But for one problem: adaptation layer fragmentation is *transpare
+1 - All of RJ's comments.
There has to be a solution that not only allows for but encourages IPv6
deployment, not prevents it.
--
Brian
On Tue, Jul 9, 2013 at 11:02 AM, RJ Atkinson wrote:
> All,
>
> I think everyone agrees that intermediate fragmentation
> (e.g. by routers having high-speed l
> Not all deployed links are built out of wired/wireless
> Ethernet or SONET. The assumption that everything is either
> Ethernet or SONET (or perhaps WDM) is a bit of a "First
> World" assumption and puts lesser-developed countries/regions
> at a significant disadvantage for Internet access.
m
All,
I think everyone agrees that intermediate fragmentation
(e.g. by routers having high-speed links in the middle of the path)
can be problematic,and that is why IPv6 does NOT require that
(i.e. RFC-2460 says that the "DF" bit is invisible but always
set for IPv6).
That noted, I agree very m
17 matches
Mail list logo
