Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Oct 2018 15:13:58 +0000

Hi Fred,

Thanks for reviewing yet another version of the draft. But I would like to push back ever-so-gently on your proposed edit.

We agree that the draft does not and should not propose the deprecation of IP Fragmentation. We also agree that IP tunnels require fragmentation. And because one critical application requires fragmentation, we cannot deprecate it.

Yes, there may be other applications that require fragmentation. IPERF may be one of them. But we don't need to mention it because we have already made our case against deprecation. Mentioning every application that requires fragmentation is over-kill.

                                                            Ron

> Message: 2
> Date: Wed, 10 Oct 2018 16:22:47 +0000
> From: "Templin (US), Fred L" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [Int-area] I-D Action:
> 	draft-ietf-intarea-frag-fragile-01.txt
> Message-ID:
> 	<554d668a29934ecf9fdf95d77d1cca52@XCH15-06-
> 08.nw.nos.boeing.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> I made this comment earlier, but it does not appear to have made it into this
> version.
> Some applications invoke IP fragmentation as a performance optimization,
> and that should be mentioned here. But, it also needs to say that RFC4963
> warns against reassembly errors at high data rates.
> 
> Suggestion is to add the following to the introduction:
> 
>    "While this document identifies issues associated with IP
>    fragmentation, it does not recommend deprecation.  Some applications
>    (e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. Others (e.g.,
>    [IPERF3]) invoke IP fragmentation as a performance optimization, but
>    can incur reassembly errors at high data rates [RFC4963]."
> 
> Thanks - Fred
> [email-masked]
> 
*************************************

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Oct 2018 08:32:57 -0700

On Mon, Oct 15, 2018, 8:14 AM Ron Bonica <[email-masked]> wrote:

> Hi Fred,
>
> Thanks for reviewing yet another version of the draft. But I would like to
> push back ever-so-gently on your proposed edit.
>
> We agree that the draft does not and should not propose the deprecation of
> IP Fragmentation. We also agree that IP tunnels require fragmentation. And
> because one critical application requires fragmentation, we cannot
> deprecate it.
>
> Yes, there may be other applications that require fragmentation. IPERF may
> be one of them. But we don't need to mention it because we have already
> made our case against deprecation. Mentioning every application that
> requires fragmentation is over-kill.
>

Iperf is just a test application so it shouldn't be mentioned here anyway.
It does illustrate another problem of fragmentation. That is if just one
fragment of a packet is lost then the whole packet is lost. So with a 1%
drop rate, a packet with two fragments has a drop rate of 2%, 10 fragments
has drop rate of 10% 64K packet makes 43 fragments of 1500 bytes so drop
rate of those packets is 35%.

I believe this amplified drop rate is a problem inherent of fragmentation
and good reason why not to use fragmentation over the  Internet. This
probably should be mentioned in the draft.

Tom

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 15 Oct 2018 15:55:57 +0000

Hi Ron,

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Ron Bonica
> Sent: Monday, October 15, 2018 8:14 AM
> To: [email-masked]
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
> 
> Hi Fred,
> 
> We agree that the draft does not and should not propose the deprecation of IP Fragmentation. We also agree that IP tunnels require
> fragmentation. And because one critical application requires fragmentation, we cannot deprecate it.
> 
> Yes, there may be other applications that require fragmentation. IPERF may be one of them. But we don't need to mention it because
> we have already made our case against deprecation. Mentioning every application that requires fragmentation is over-kill.

OK, but iperf3 is proof that some applications may see greater performance by
intentionally invoking IP fragmentation. I know of at least one other application
(a real application; not a test app) that leverages IP fragmentation for this very
reason. So, I think that the document should at least acknowledge this fact but
at the same time cite [RFC4963] as evidence that the practice is dangerous.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Oct 2018 09:46:36 -0700

Two points I'd like to make: 

1) it is very important to list at least one other application besides
tunneling that relies on fragmentation. Frankly, unless the list is
prohibitively long, it should absolutely be included to help avoid this
document laying the foundation for future arguments to deprecate
fragmentation "except for tunnels". Iperf is more than just a test
application; it speaks to the issue of network monitoring using active
injection using that tool, so it's more than 'just a test application'. 

2) The statistics below assume independent drop probabilities. A smarter
way to handle fragment drops was realized in the ATM/AAL5 days, i.e.,
when you drop a fragment at a queue, then drop all other associated
fragments (if possible, if nearby, etc.). Note that tail drop would
already potentially do this at least partly and other drop mechanisms
might be extended to have similar properties without actually scanning
the queue. 

Joe

On 2018-10-15 08:32, Tom Herbert wrote:

> Iperf is just a test application so it shouldn't be mentioned here anyway. It does illustrate another problem of fragmentation. That is if just one fragment of a packet is lost then the whole packet is lost. So with a 1% drop rate, a packet with two fragments has a drop rate of 2%, 10 fragments has drop rate of 10% 64K packet makes 43 fragments of 1500 bytes so drop rate of those packets is 35%. 
> 
> I believe this amplified drop rate is a problem inherent of fragmentation and good reason why not to use fragmentation over the  Internet. This probably should be mentioned in the draft.. 
> 
> Tom 
> 
>> Ron
>> 
>>> Message: 2
>>> 08.nw.nos.boeing.com [1]>

Links:
------
[1] http://08.nw.nos.boeing.com

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Oct 2018 09:52:18 -0700

On 2018-10-15 08:55, Templin (US), Fred L wrote:

> ...
> So, I think that the document should at least acknowledge this fact but

The points raised in RFC6864 Sec 5.2 might have mitigated the situation
described in 4963. I.e., the dangerous practice is using a large default
timeout for queued fragments, rather than a timer based on the expected
reassembly delay (which can be measured and used as an estimate
automatically). 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Oct 2018 09:59:20 -0700

On Mon, Oct 15, 2018 at 9:46 AM, Joe Touch <[email-masked]> wrote:
> 2) The statistics below assume independent drop probabilities. A smarter way
> to handle fragment drops was realized in the ATM/AAL5 days, i.e., when you
> drop a fragment at a queue, then drop all other associated fragments (if
> possible, if nearby, etc.). Note that tail drop would already potentially do
> this at least partly and other drop mechanisms might be extended to have
> similar properties without actually scanning the queue.
>
Joe,

That doesn't improve the drop rate. At best it's just providing early
drop to save some resources. I don't think there's any argument that
fragmentation has higher goodput than equivalent unfragmented stream
of packets.

Tom

>> because one critical application requires fragmentation, we cannot deprecate
>> it.
>>
>> be one of them. But we don't need to mention it because we have already made
>> our case against deprecation. Mentioning every application that requires
>> fragmentation is over-kill.
>
>
> probably should be mentioned in the draft..
>
> Tom
>
>>
>>
>>                                                             Ron
>>
>>
>> > Message: 2

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Oct 2018 11:00:33 -0700

On 2018-10-15 09:59, Tom Herbert wrote:

> That doesn't improve the drop rate.

I'm proposing dropping associated fragments instead of other (new)
fragments. 

This would result in the same number of bytes and packets dropped (thus
freeing up the same resources both per packet and per byte), but would
clearly reduce the number of impacted reassembled packets. 

Please explain why you think this would not improve the drop rate, just
as *did* for ATM/AAL5. 

> At best it's just providing early
> drop to save some resources.

Which frees those resources up for other packets/fragments... 

> I don't think there's any argument that

Agreed. But your math is incorrect unless drops are uncorrelated;
correlated losses could result in nearly the same impact on fragmented
packets as non fragmented packets. 

Yes, it won't get better for fragments but it doesn't have to get worse,
or at least as linearly worse as you claim. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Oct 2018 11:28:28 -0700

> clearly reduce the number of impacted reassembled packets.
Why is that clear? Of course when dropping a fragment then it makes to
drop all related fragments of the train. But there's no guarantee that
the node even sees any of the other fragments. Something like RED
might help with locality of fragments arriving is true, but only
offers heuristics to mitigate the problem.

> Please explain why you think this would not improve the drop rate, just as
> *did* for ATM/AAL5.
>
>
>
> Agreed. But your math is incorrect unless drops are uncorrelated; correlated
> losses could result in nearly the same impact on fragmented packets as non
> fragmented packets.

Dropping at oversubscribed queue isn't the only source of drops, a
lossy radio link could produce uncorrelated losses for instance.
Besides that, if you want to consider correlated drops then the math
is very different. For instance, suppose someone sends 10 TCP segments
which could alternatively be sent as one TCP segment and 10 fragments.
Now suppose last 5 packets are dropped in each case. Goodput in TCP is
5 packets worth of data, goodput in fragmentation is zero.

>
> Yes, it won't get better for fragments but it doesn't have to get worse, or
> at least as linearly worse as you claim.

It would be interesting to see the reall world case where
fragmentation can do better or as good (either in goodput or
performance), but I'm doubtful that exists.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 15 Oct 2018 18:41:10 +0000

> performance), but I'm doubtful that exists.

One of the applications I am referring to works over space links where there
are long delays, but no congestion and hence little/no IP packet/fragment loss.
This is a case of a long, fat network (LFN) and because there is significant delay
(reliable) UDP is used instead of TCP.

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Mon, 15 Oct 2018 11:42:14 -0700

> at the same time cite [RFC4963] as evidence that the practice is dangerous.

I'd like to push back on the meaning of "require". iPerf *uses* fragmentation, and other applications use fragmentation, for the reason that you state. If fragmentation didn't exist or didn't work as expected, I'll bet that a variation on iPerf and the other applications in question would come into being that used PLPMTUD or PMTUD (such as using iPerf/TCP with --set-mss), because something that works at all is better than something that doesn't work at all. What you get from fragmentation is an optimization.

It would also be interesting to get a list of the applications you're discussing. I can imagine that NFS is among them; it kicks out 8K byte RPC messages on UDP (IIRC) depending on IP fragmentation to make them actually arrive across an Ethernet or an IP network with <576 byte MTUs. But how many of us are using NFS? Is that a real requirement? I would go down the list of applications and ask the same question: does the application simply use it because it is there, or does the application inherently depend on it?

Following Merriam-Webster, I find myself thinking of a "requirement" as "a necessity" or "something essential to the existence or occurrence of something else". "We use it and we think we have a good reason, but it would work without it" doesn't seem to me to fall into the same category.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Oct 2018 11:51:58 -0700

> (reliable) UDP is used instead of TCP.

Okay, that could be one use case. But then I have to ask: why not just
crank up MTUs to a high number to eliminate fragmentation overhead?

Tom

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 15 Oct 2018 18:52:15 +0000

HI Fred,

> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, October 15, 2018 11:42 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Ron Bonica <[email-masked]>; [email-masked]
> I'd like to push back on the meaning of "require".

I did not use the word "require" - that came into the discussion through someone
else's post. The term I used was "performance optimization".

Thanks - Fred

> iPerf *uses* fragmentation, and other applications use fragmentation, for the
> reason that you state. If fragmentation didn't exist or didn't work as expected, I'll bet that a variation on iPerf and the other
> applications in question would come into being that used PLPMTUD or PMTUD (such as using iPerf/TCP with --set-mss), because
> something that works at all is better than something that doesn't work at all. What you get from fragmentation is an optimization.
> 
> It would also be interesting to get a list of the applications you're discussing. I can imagine that NFS is among them; it kicks out 8K byte
> RPC messages on UDP (IIRC) depending on IP fragmentation to make them actually arrive across an Ethernet or an IP network with
> <576 byte MTUs. But how many of us are using NFS? Is that a real requirement? I would go down the list of applications and ask the
> same question: does the application simply use it because it is there, or does the application inherently depend on it?
> 
> Following Merriam-Webster, I find myself thinking of a "requirement" as "a necessity" or "something essential to the existence or
> occurrence of something else". "We use it and we think we have a good reason, but it would work without it" doesn't seem to me to
> fall into the same category.

---

From: Fred Baker <[email-masked]>
Date: Mon, 15 Oct 2018 11:55:01 -0700

> On Oct 15, 2018, at 11:41 AM, Templin (US), Fred L <[email-masked]> wrote:
> 

So the issue isn't fragmentation, it is the ability to carry streams of packets. Fragmentation becomes a way to create and consume streams of packets.

If the space-based application is the one I'm thinking of (SCPS), the fundamental reasons it doesn't use TCP is because of the RTT when setting up a session, and the number of RTTs that have to happen before a session develops a reasonable estimate of channel capacity. It operates as command/telemetry - the sending application sends a sequence of enumerated packets, the receiving application reports what it receives, and the sending application retransmits the subset that didn't make it through. I find myself thinking of RFCs 2525 and 2760. What I know about such applications tells me that you *have* to have an estimate of channel capacity and the ability to, in essence, have an open and operational channel when you need it - such as sending a burst of segments from Pluto to Earth without session set-up or capacity estimation, and very probably operating in a command/telemetry model in the application.

I have no problem with space-based protocols or applications. However, at some point I wonder whether the tail is wagging the dog, so to speak. To make these applications work, NASA and others modify the protocols or substitute entirely new ones. If the protocol specification is a point of departure, I don't see any reason that space-based applications can't say "unlike our terrestrial counterparts, we do use fragmentation and reassembly".

---

From: Fred Baker <[email-masked]>
Date: Mon, 15 Oct 2018 12:05:44 -0700

> On Oct 15, 2018, at 11:52 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> The term I used was "performance optimization".

Then we agree that it is an optimization, and not a requirement.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 15 Oct 2018 19:06:09 +0000

Hi Tom,

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Monday, October 15, 2018 11:52 AM
> Cc: Joe Touch <[email-masked]>; Ronald Bonica <[email-masked]>; int-area <[email-masked]>

It is a good question, but it is not always possible to lay hands on the media to
set a larger MTU. And some link types (e.g., legacy Ethernet) don't support
larger MTUs anyway. Of course, modern Ethernet with 9K jumbos can do
more but some applications may want to push the UDP datagram size all
the way to 64K.

From what I saw when I was working with iperf3. By default, it uses 8KB
UDP datagram sizes when it runs on Ubuntu. By setting the UDP datagram
size to a smaller value (i.e., one that needs less IP fragmentation) it shows
a performance decrease. By setting the UDP datagram size to a larger value
(i.e., one that needs more IP fragmentation) it shows a performance increase.

Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 15 Oct 2018 19:07:41 +0000

Hi Fred,

> Sent: Monday, October 15, 2018 12:06 PM

But then again, sometimes optimizations are required.

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Oct 2018 12:12:26 -0700

On 2018-10-15 11:28, Tom Herbert wrote:

> the node even sees any of the other fragments.

Agreed, but it might...

> Something like RED

We agree that uncorrelated losses are uncorrelated. But queue drops
don't always need to be uncorrelated.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Oct 2018 12:13:27 -0700

> (i.e., one that needs more IP fragmentation) it shows a performance increase.
Yes, this because it's better to wake application once than mutiple
times for smaller packets.

Can you provide any more information about the L2 protocols for the
space link? Do they do their own packetization implementing
reliability and I'm guessing a bunch of FEC?

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Oct 2018 12:23:47 -0700

Sorry - getting back to the last example. 

> 5 packets worth of data, goodput in fragmentation is zero.

Yes, you can create a strawman we're not considering and win. 

I can also create a case where taking a single large TCP segment and
breaking it into 10 fragments, then sending each fragment 10x has MUCH
higher probability of getting through (this I think was called TCP
Boston). 

But neither case is relevant to this doc; the relevant case is where the
packets need to be fragmented to go over a layer that cannot change its
transmitted payload size (tunnels are the typical case). 

> performance), but I'm doubtful that exists.

"as good" happens when losses happen at queues and drops can be forcibly
correlated within the set of fragments for a segment; this isn't a
trivial case -- it's what happens when lots of little fragments are
muxed in queues at switches such as happened with ATM/AAL5. 

"better" happens when the large packet can't get through at all, i.e.,
the tunnel case. 

That's all we're aiming at. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Oct 2018 12:28:00 -0700

> times for smaller packets.

Smaller packets have lower throughput because of many other per-packet
overheads which include the header length overhead relative to the
payload and setup costs for DMA and IP checksum, etc. 

The issue of waking the app matters less if using polling, which is more
typical than relying on interrupts for high-speed networking. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Oct 2018 12:50:26 -0700

On Mon, Oct 15, 2018 at 12:28 PM, Joe Touch <[email-masked]> wrote:
> overheads which include the header length overhead relative to the payload
> and setup costs for DMA and IP checksum, etc.
>
UDP is eight bytes overhead, IP fragmentation header is eight bytes.
So fragmenting one UDP packet versus sending the equivalent packets as
UDP datagrams have similar wire overhead (I belive the net difference
is eight extra bytes for fragmentation). Stack procesing of UDP versus
a fragment also should not particularly different. Both require a
table lookup, but it's also true that much more effort will go into
optimizing UDP than fragmentation because of much higher usage.

> typical than relying on interrupts for high-speed networking.

There's still overhead, for instance each UDP message needs to be
separately read, but then we also have recvmmsg that could address
that. It's unlikely iperf uses that.

I don't believe that host processing of the two scenarios should be
particularly different if all the best API is used. I still intend on
testing this soon.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Oct 2018 19:50:25 +0000

Hi Tom,

This is reminiscent of loss amplification in IP-over-ATM. In IP-over-AM, if you lose one cell, you have to retransmit every cell belonging to the packet. In reality, you have to retransmit every cell belonging to the TCP window.

This was a real problem in ATM, because many, many  packets were broken into multiple ATM cells. So, the likelihood of dropping a cell that belonged to a large packet was very high.

It isn’t so much a problem in IP, because very few packets are fragmented. So, the odds of dropping a fragment are pretty slim.

If you feel strongly about this, we can craft a new section. What do you think?

                                                                               Ron

From: Tom Herbert <[email-masked]>
Sent: Monday, October 15, 2018 11:33 AM
To: Ron Bonica <[email-masked]>
Cc: int-area <[email-masked]>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt

On Mon, Oct 15, 2018, 8:14 AM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Hi Fred,

I believe this amplified drop rate is a problem inherent of fragmentation and good reason why not to use fragmentation over the  Internet. This probably should be mentioned in the draft.

Tom

                                                            Ron

> From: "Templin (US), Fred L" <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> 08.nw.nos.boeing.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__08.nw.nos.boeing.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=j5RV_OQrl2LRseZu-mAfda58Zy7fMLAZNDUlrNBst0Q&s=pPjhdfQeYxN1GkZuFB3h6IvsB7TXljD-zq7sP-7btsU&e=>>
> [email-masked]<mailto:[email-masked]>
>

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_int-2Darea&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=j5RV_OQrl2LRseZu-mAfda58Zy7fMLAZNDUlrNBst0Q&s=hglnDcp0kdMwwSUjZ8n_DrRP7G4jj6edlH0v0u0ne9g&e=>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Oct 2018 19:53:11 +0000

Fred,

Can you provide a reference to one of those applications? If so, I would be glad to add it to the draft.

                                                  Ron

> From: Templin (US), Fred L <[email-masked]>
> Sent: Monday, October 15, 2018 11:56 AM
> To: Ron Bonica <[email-masked]>; [email-masked]
> Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
> 
> Hi Ron,
> 
> > We agree that the draft does not and should not propose the
> > deprecation of IP Fragmentation. We also agree that IP tunnels require
> > Yes, there may be other applications that require fragmentation. IPERF
> > may be one of them. But we don't need to mention it because we have
> already made our case against deprecation. Mentioning every application that
> intentionally invoking IP fragmentation. I know of at least one other
> application (a real application; not a test app) that leverages IP fragmentation
> for this very reason. So, I think that the document should at least acknowledge
> this fact but at the same time cite [RFC4963] as evidence that the practice is
> dangerous.
> 
> Thanks - Fred
> 
> >                                                             Ron
> >
> >
> > > Message: 2
> > > I made this comment earlier, but it does not appear to have made it
> > > into this version.
> > > Some applications invoke IP fragmentation as a performance
> > > optimization, and that should be mentioned here. But, it also needs
> > > to say that RFC4963 warns against reassembly errors at high data rates.
> > >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_int-2Darea&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > TXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=8qGsBOSZ_rXQ-
> >
> C1vm92o4jL3pkSBS96pwpQOnO0QM3g&s=oHN6iDxb9N6hlOa5n2zw_gl6QF
> Qs-1Aq8CwJ2
> > pgKaq8&e=

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Oct 2018 12:56:15 -0700

On Mon, Oct 15, 2018 at 12:50 PM, Ron Bonica <[email-masked]> wrote:
> Hi Tom,
>
>
>
> This is reminiscent of loss amplification in IP-over-ATM. In IP-over-AM, if
> you lose one cell, you have to retransmit every cell belonging to the
> packet. In reality, you have to retransmit every cell belonging to the TCP
> window.
>
>
>
> This was a real problem in ATM, because many, many  packets were broken into
> multiple ATM cells. So, the likelihood of dropping a cell that belonged to a
> large packet was very high.
>
>
>
> It isn’t so much a problem in IP, because very few packets are fragmented.
> So, the odds of dropping a fragment are pretty slim.

Right, but my claim is that very few IP packets are fragmented because
of this problem. Even if all the middleboxes in the world were
instantly fixed, the loss amplification problem of fragmentation is
still present and still a reason to avoid fragmentation. This problem
is inherent to IP fragmentation.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Oct 2018 19:58:42 +0000

Hi Joe,

Inline……

From: Joe Touch <[email-masked]>
Sent: Monday, October 15, 2018 12:47 PM
To: Tom Herbert <[email-masked]>
Cc: Ron Bonica <[email-masked]>; int-area <[email-masked]>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt

1)   it is very important to list at least one other application besides tunneling that relies on fragmentation. Frankly, unless the list is prohibitively long, it should absolutely be included to help avoid this document laying the foundation for future arguments to deprecate fragmentation "except for tunnels". Iperf is more than just a test application; it speaks to the issue of network monitoring using active injection using that tool, so it's more than 'just a test application'.

Could you provide a few references? If you can provide one or two, I would be glad to include them and IPERF in the draft.

2)   The statistics below assume independent drop probabilities. A smarter way to handle fragment drops was realized in the ATM/AAL5 days, i.e., when you drop a fragment at a queue, then drop all other associated fragments (if possible, if nearby, etc.). Note that tail drop would already potentially do this at least partly and other drop mechanisms might be extended to have similar properties without actually scanning the queue.

While I agree that the draft doesn’t need to address this issue, I don’t think the ATM/AAL5 solution helped much. The source still had to retransmit all cells when one was lost.

Joe

Tom

                                                            Ron

> 08.nw.nos.boeing.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__08.nw.nos.boeing.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=elYii16ueBFkEZ0VPl7z7IUx3Y05Pj6cfWWEgzzFaOw&s=4Y7MzXXkZYzOR3TG7LEeajScn8EGF7U28T7T66VoiSo&e=>>

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_int-2Darea&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=elYii16ueBFkEZ0VPl7z7IUx3Y05Pj6cfWWEgzzFaOw&s=O9clTv10fUjUtB-1cCsEdPq_n74R44PPUj1LxfU2aac&e=>

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_int-2Darea&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=elYii16ueBFkEZ0VPl7z7IUx3Y05Pj6cfWWEgzzFaOw&s=O9clTv10fUjUtB-1cCsEdPq_n74R44PPUj1LxfU2aac&e=>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Oct 2018 20:04:20 +0000

Can you provide a reference that I can use in the document?

> Sent: Monday, October 15, 2018 2:41 PM
> To: Tom Herbert <[email-masked]>; Joe Touch
> <[email-masked]>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 15 Oct 2018 20:26:34 +0000

Hi Ron,

Another application besides iperf3 is the Licklider Transmission Protocol (LTP)
convergence layer of the Interplanetary Overlay Network (ION) implementation
of Delay Tolerant Networking (DTN). But, I would prefer to just list iperf3 itself
as it can be pointed to as a general archetype for this class of applications.

Thanks - Fred

> From: Ron Bonica [mailto:[email-masked]]
> Sent: Monday, October 15, 2018 12:53 PM
> To: Templin (US), Fred L <[email-masked]>; [email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Oct 2018 20:48:03 +0000

Hi Fred,

I don't see the work "fragment" in RFCs 5325 or 5326. Can you help me with better references?

                                                   Ron

> Sent: Monday, October 15, 2018 4:27 PM
> convergence layer of the Interplanetary Overlay Network (ION)
> implementation of Delay Tolerant Networking (DTN). But, I would prefer to
> just list iperf3 itself as it can be pointed to as a general archetype for this class
> of applications.
> 
> Thanks - Fred
> 
> > > > Yes, there may be other applications that require fragmentation.
> > > > IPERF may be one of them. But we don't need to mention it because
> > > > we have
> > > already made our case against deprecation. Mentioning every
> > > application that requires fragmentation is over-kill.
> > >
> > > OK, but iperf3 is proof that some applications may see greater
> > > performance by intentionally invoking IP fragmentation. I know of at
> > > least one other application (a real application; not a test app)
> > > that leverages IP fragmentation for this very reason. So, I think
> > > that the document should at least acknowledge this fact but at the
> > > same time cite [RFC4963] as evidence that the practice is dangerous.
> > >
> > > Thanks - Fred
> > >
> > > >                                                             Ron
> > > >
> > > >
> > > > > Message: 2
> > > > > I made this comment earlier, but it does not appear to have made
> > > > > it into this version.
> > > > > optimization, and that should be mentioned here. But, it also
> > > > > needs to say that RFC4963 warns against reassembly errors at high
> data rates.
> > > > >
> > > > man_listinfo_int-
> 2Darea&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > > ndb3voD

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 15 Oct 2018 20:54:15 +0000

Hi Ron,

You won't see the word "fragment" in the specs, and you won't even
see it in the code. What does happen is that the code allows the setting
of a UDP datagram size as large as 64KB (minus headers) and then leaves
it up to the kernel to do the fragmenting.

Here is a pointer to the code:

https://sourceforge.net/projects/ion-dtn/

Thanks - Fred

> Sent: Monday, October 15, 2018 1:48 PM

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Oct 2018 14:06:34 -0700

On 2018-10-15 12:58, Ron Bonica wrote:

> Hi Joe, 
> 
> Inline...... 
> 
> FROM: Joe Touch <[email-masked]> 
> SENT: Monday, October 15, 2018 12:47 PM
> TO: Tom Herbert <[email-masked]>
> CC: Ron Bonica <[email-masked]>; int-area <[email-masked]>
> SUBJECT: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt 
> 

I doubt we can find strict references. The issue is whether network
administrators build it into their scripts or other toolkits. 

> While I agree that the draft doesn't need to address this issue, I don't think the ATM/AAL5 solution helped much. The source still had to retransmit all cells when one was lost.

It helped a lot. Without the solution, you could build a switch whose
buffers were never underrun but never got a single packet through -
because the interleaving of fragments from many inputs would fill the
output buffer of a single output to the point where EVERY packet lost at
least one fragment. 

By allowing "all or none" through the switch, the output buffer avoided
needing N X (# fragments) of buffering. 

Joe