ietf
[Top] [All Lists]

Re: Is Fragmentation at IP layer even needed ?

2016-02-08 14:44:24
Seems to me that we might be misreading the original proposal. There
are two ways to read it:

1) In future all Internet routing gear MUST NOT fragment IP packets.
2) Take fragmentation out of the endpoint stack.

It seems to me that these are very different proposals. I fully
endorse the first if we add the caveat 'except to support legacy, non
jumbo frame capable links'.

When those limits were set, I was programming a machine with 32K of memory.


The second is obviously premature. But we could move the description
of fragmentation from being a 'current feature' to a 'legacy support'
issue.

Didn't we have a presentation on 'sane ways to create TCP like things
atop UDP' in an IETF plenary a couple of meetings back?

We seem to be something of a prisoner of the 1980s era Ethernet spec.
I am pretty sure that most of the equipment I buy is capable of doing
jumbo packets. But quite a few of them turn out to require jumbo
packets to be turned on by hand.

The ability to consistently support 64KB packets and thus high
throughput is potentially one of the main selling points for IPv6. I
don't believe in trying to persuade people to move to IPv6 through
differences in function. It will be a decade minimum before I consider
making use of an IPv6 feature not supported in IPv4 in an application
protocol. Performance is something else, I will encourage people to
upgrade to get faster performance.


Given all the sprockets, widgets and doo-dahs in the IPv6 spec, I am
pretty sure that it should be possible to get it to correctly
negotiate use of jumbo frames in an environment where fragmentation
might occur on the path and react accordingly.

So this is really a problem of UDP. And there I see three categories
of application:

1) DNS - is in a class of its own due to its function as the Internet
discovery protocol.

2) 'Can't help' - there are many many UDP applications today that have
all dealt with fragmentation in their own idiosyncratic ways.

3) 'Right way to use UDP' - a new specification describing a 'right'
way to use UDP to get TCP like features in a NAT compatible, etc
fashion could provide value.


I have been coding the past 6 months and doing little else. What
happened to that UDP proposal?