On 19/11/2024 23:58, lloyd.w...@yahoo.co.uk wrote:
These proposed changes to UDP are thoughtprovoking.
When UDP-Lite (RFC3828) was proposed, it was eventually shunted to its own IP
protocol number, rather than risk messing up existing UDP implementations and
semantics for even a very minor change. I gather that move to a different port
was done very late in the process.
The changes proposes in UDP options and in parcelling seem much much larger.
Surely they should be treated as UDP-Lite was, and as UDP-alike but not as UDP,
and given their own IP protocol number?
thanks
Lloyd Wood
lloyd.w...@yahoo.co.uk
I think Lloyd this set of therads is conflating two things:
UDP Options has been developed over many years as a specification, and
(at least in tsvwg) is thought complete - we have evidence the method
works across existing networks and the WG has analysed whether we can
extend it safely. It's been through WGLC and should hopefully complete
AD review soon. It's an addition to UDP.
IP parcels has been presented at the IETF, but as far as I know, hasn't
yet been adopted. I don't expect this to be ready for quite some time,
especially since it anticipates new devices on-path that have been
optimised for very large packets. In most parts of the network, we are
still struggling to support near 1500B. If packets are > 64 KB as
imagined, there will be many more conbsiderations, not least how
fragmentation is handled within the network and the relationship to loss
recovery, congestion control, etc. If the IETF decides this is an
important use-case, I see this as further out, with many things to decide.
Best wishes,
Gorry
On Wednesday 20 November 2024 at 05:12:00 GMT+11, to...@strayalpha.com
<to...@strayalpha.com> wrote:
Hi, all,
I have not investigated this issue. Any new UDP option proposal would need to
be evaluated in detail AND would need to follow the design requirements in the
UDP options doc.
Further, I would urge any option that is per-IP packet to be an IP option; UDP
options are intended for user endpoints, not the (existing) protocol subsystem
per se. I don’t yet understand whether the proposed parcel parameters should be
an IP option or UDP option, but UDP options are NOT intended as a place you can
put info that you don’t want to or can’t put in IP options per se. IP options
are per IP packet; UDP options are per UDP message. We’d need to understand why
parcels are fiddling with UDP option space - which may already be used by the
UDP endpoints.
Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
On Nov 14, 2024, at 4:54 PM, C. M. Heard <he...@pobox.com> wrote:
Fred and WG participants,
I have finally freed up some cycles to read draft-templin-6man-parcels2-14, and
I have found some issues with it that need to be addressed with respect to its
handling of UDP.
The big one -- if I have correctly understood what I have read -- is that it's
possible for a single parcel of a parcellated UDP packet to be turned into a
stand-alone UDP packet (see Section 7.1) and delivered to an end system as such
(see Section 7.4). That packet would contain a Parcel Parameters UDP Option to
tell the endpoint host that the packet is a parcel and not a complete UDP
datagram, but the option kind is taken from the SAFE option space (KIND = 127;
see draft-ietf-tsvwg-udp-options#section-10). Legacy endpoints that do not
understand UDP options will ignore that SAFE option and will deliver the parcel
as if it were a complete UDP datagram. That, to my mind, is completely
unacceptable. Unlike TCP, which is a byte-stream protocol in which segment
boundaries have no meaning for the upper layer, UDP is a datagram protocol in
which message boundaries are meaningful to the upper layer. The protocol has a
contract with the upper layer to deliver a message as it was submitted or not
at all. Delivering a parcel in a manner that can be misinterpreted as a
complete datagram violates that contract.
It is possible to repair this defect by making the Parcel Parameters Option, or
something with equivalent functionality, into an UNSAFE option. My suggestion
would be to define an UNSAFE version of the existing FRAG option (see
draft-ietf-tsvwg-udp-options#section-11.4) -- let's call it UFRAG -- that would
allow for packet sizes greater than 65,535 bytes. The same option could be used
to send singleton advanced jumbo packets as atomic fragments. This would avoid
any need to modify the base UDP and UDP Options specifications.
Additionally: during the review of draft-ietf-tsvwg-udp-options, Joe Touch
correctly pointed out that RFC 2765 (and its predecessor RFC 2147) failed to
note that it updated RFC 768. Similar concerns apply to TCP. If this draft foes
forward, it should note that it updates the UDP and TCP specifications, and it
should get buy-in from TSVWG and TCPM.
Thanks and regards,
Mike Heard
On Sun, Sep 29, 2024 at 3:51 PM C. M. Heard <he...@pobox.com> wrote:
Fred,
I currently hold the editing pen for the changes to the UDP Options draft that
have been requested prior to the shepherd report, and my intention is to remain
silent about how, if at all, IP Parcels and Advanced Jumbos (AJs) will support
UDP Options.
I'll provide comments on the IP Parcels and Advanced Jumbos work at a later
date, when I have spare intellectual cycles to fully comprehend the contents of
draft-templin-6man-parcels2. At this point I must confess that, like Brian, I
do not understand how a receiver will locate the options trailer in the case of
an IP Payload Length exceeding 65535. Like Joe, I think it would be better to
put the options just after the UDP header and make a new UNSAFE option to
delimit the position where the options end and the user data begins.. But that
discussion (and the corresponding update to the UDP options draft) can occur
when it is ripe; IMO that is not the case at this time.
Respectfully,
Mike Heard
On Sun, Sep 29, 2024 at 3:07 PM Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote:
IP parcels and Advanced Jumbos (AJs) of all sizes ranging from 1 to 2^32 are now eligible
for using UDP options. This is just one way in which they offer a better
service than RFC2675
Jumbograms, but there are also many others.
Joe, you can either note this in your draft or just leave it be and let my draft do an
“updates UDP options”.
Thank you - Fred
From: Brian Carpenter <brian.e.carpen...@gmail.com>
Sent: Saturday, September 28, 2024 2:20 AM
To: Gorry (erg) <go...@erg.abdn.ac.uk>
Cc: Joe Touch <to...@strayalpha.com>; Templin (US), Fred L <fred.l.temp...@boeing.com>; Tim Chown
<tim.ch...@jisc.ac.uk>; Internet Area <Int-area@ietf.org>; IPv6 List <i...@ietf.org>; tsvwg IETF
list <ts...@ietf.org>
Subject: [EXTERNAL] Re: [tsvwg] Re: UDP options [was IP Parcels and Advanced
Jumbos (AJs)]
EXT email: be mindful of links/attachments.
That works for me..
(via tiny screen & keyboard)Regards, Brian Carpenter
On Sat, 28 Sept 2024, 19:08 Gorry (erg), <go...@erg.abdn.ac.uk> wrote:
See below> On 28 Sep 2024, at 04:05, Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:> > Joe,> On 28-Sep-24 03:13, to...@strayalpha.com wrote:>>>> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L
<Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote:>>> >>>> Indeed. But if sendmsg() and recvmsg() can and do generate RFC2675 packets, it means that any discussion of obsoleting RFC2675 should be>>>> off the table.>>>
>>> No one that I know of has suggested obsoleting RFC2675 - my documents do not say "obsoletes" (nor even "updates”).>> That approach to UDP jumbo grams is incompatible with UDP options.>> And yes, there was a proposal to move
that RFC to historic:>> Jones, T., G. Fairhurst, "Change Status of RFC 2675 to Historic," draft-jones-6man-historic-rfc2675, May 2019.>> We COULD have a new option with a longer length, but that’s not in our baseline draft.> > Wouldn't
that be tricky, because the options follow the whole payload as I understand it? So a JumboUDPgram has to be received in full, however big it is, before the option saying that it's a jumbo can be received and interpreted.> > Where the udp-options draft
says:> >>> The technique has been proposed for deprecation [Jo19].> > I think you'd better change it to something like:> > The technique is known to be in active use in special situations, so cannot reasonably be deprecated. However, users of
this technique cannot simultaneously use UDP options.> > Brian> I do not think the I-D needs to say anything about the deployment status of jumbograms, that another topic.I suggest if people wish, we just say that users of this technique can or cannot
simultaneously use UDP options.Gorry > >
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
