Subject: [Tsvwg] Last Call: The UDP Lite Protocol to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 01 May 2002 11:33:28 -0400

The IESG has received a request from the Transport Area Working Group
Working Group to consider The UDP Lite Protocol
<draft-ietf-tsvwg-udp-lite-00.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by May 15, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-lite-00.txt

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 May 2002 13:17:03 -0400

this document opens up a big can of worms.

it's always been assumed that the link layer's job was to try to deliver
packets without error.  the UDP and TCP checksums have never been deemed
adequate to reliably detect errors from any point in the transmission, 
but only to detect occasional errors that can occur when switching from
one link layer to another, in hardware network interfaces, or in software.
(and perhaps, to detect the very occasional error that escapes the more
robust error detection mechanisms provided by link layers)

now we're proposing a transport layer that explicitly doesn't assume that 
the link layer's job is to deliver packets without error.  should a link 
layer handle "UDP Lite" packets differently from other kinds of IP 
packets, say providing FEC with other IP types and not with UDP Lite?
if so, what error rate is acceptable for UDP Lite packets?  this needs to 
be specified, or at least discussed, and it's not just a matter of what 
percentage of packets can have errors but how many bits per packet can be 
in error and the distribution (within a packet) of those erroneous bits.

I also think the name "UDP Lite" is likely to be confusing.
As alternatives, I'd propose EPDP (for error-prone datagram 
protocol) or URDP (for unreliable datagram protocol)
or perhaps LDP (for lossy datagram protocol). 

Keith

---

From: Phillip Conrad <[email-masked]>
Date: Thu, 02 May 2002 23:37:25 -0400

Keith,
    I hear your concern about what this protocol implies in terms of the 
general expectation about the relationship between the link layer checksum 
and the transport layer checksum.    To fully realize the benefits of UDP 
Lite, it does seem that one would need to also allow for partial checksum 
(i.e. CRC?) coverage at the link layer as well.

Regarding your comments:

>  Should a link

To my reading, your question "Should a link layer handle 'UDP Lite' packets 
differently from other kinds of IP packets?" is at least partially 
addressed in the draft in the section titled "Lower Layer 
Concerns".      However, you raise a good point with respect to 
FEC...  there is no mention of what to do in the case of link layers that 
use FEC to enhance reliability.

My best guess of the authors' intent is that FEC would *not* be appropriate 
for UDP Lite packets, unless it were applied in some way as to only provide 
FEC for the "error sensitive" portion of the packet.   However, it would 
probably be an improvement if the authors were to clarify this themselves.

On the other hand, I don't see a need to specify an acceptable error rate, 
or acceptable error distribution for the resulting packets.   As I 
understand it, the basic idea here is to divide the UDP datagram into two 
portions:

(1) an error sensitive part, which should be treated with all the same due 
diligence in preventing/detecting errors that has been and is currently 
used for any UDP datagram

(2) an error insensitive part, which should be left alone as much as 
possible...  that is, don't waste resources inside the network plumbing 
trying to correct bit errors that the end user may not care that much about 
anyway (because some kind of bit-error resilient codec is already in use 
anyway.)

So the answer is, I think, "for part (1) of the packet, do whatever you do 
now, and for part (2), do NOTHING, and let the chips (or in this case, bit 
errors), fall where they may."  Of course, it is possible that I might be 
mistaken in either my understanding of the protocol, or of your concern.

Anyway, my sense is that this is a good proposal.  (I note that it is on 
the list of things that the 3GPP folks are looking for from the IETF, 
though I can't tell you anything about what the particular significance of 
that is, if anything.)    See: http://www.3gpp.org/TB/Other/IETF.htm  (Item 
14.) Maybe someone on the list with more understanding than me might 
comment on the significance of this proposal to that effort?

>protocol)
>or URDP (for unreliable datagram protocol)

I actually don't find UDP-Lite to be particularly confusing, but for the 
sake of discussion, here's another take on your suggestions for alternative 
names:

* I'm not particularly keen on "unreliable datagram protocol"; it strikes 
me as redundant according to the usual understanding of datagram (just as 
"reliable datagram" is an oxymoron).
* "Lossy Datagram Protocol"  strikes me as an accurate use of terminology; 
I could live with this one.
*  Though you might or might not have intended it, I hope you will not take 
too much offense if I point out that "Error Prone Datagram Protocol" seems 
like a negative commentary about the protocol rather than a good 
alternative name.

All in all, to me it seems like a good solid proposal.   An additional 
sentence clarifying what to do w.r.t FEC in the link layer could make it 
stronger, but it seems to me ok as it is.

Phill

PS: One typo (spelling): consider changing "layeers" to "layers" :-)

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 May 2002 02:34:57 -0400

> or acceptable error distribution for the resulting packets.   

I don't see how you can use udp-lite without being able to make some 
reasonable assmptions about the error rate of the underlying media.  
It's not the case that higher layers don't care at all about the error
rate - they just can make somewhat greater use of a packet that has 
some amount of transmission error than they can of a dropped packet.

but there's a fair amount of variation between the bit error rates of
link layers (especially with radio/satellite links).  FEC might be
needed for some link layers, even for UDP-Lite, and not in others.
it depends on the error rate and distribution, and this draft provides
no guidance about that.

like I said, this opens up a big can of worms.  I don't see the idea
as particularly dangerous - at least, not if you're using another IP
protocol type. but requiring IP link layers to be sensitive to 
higher-layer protocols bothers me, and writing applications without being
able to know something about the reliability of the underlying service
also bothers me.

Keith

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 7 May 2002 15:23:19 -0700

All,

There has been interest within the RDMA group to impose separate Header and
Payload checks as a means to reduce the size of a FIFO to handle Payload
placement.  Should there be a problem detected within the payload, the point
in time where this is handled can be delayed provided Header information is
known to be correct before hand.  This information deals with attributes
such as Buffer ID, Offset, and Length.  The simple checksum proposed for
UDP-lite would not allow an adequate level of assurance for such use.  Why
is such a weak level of checking being used?  This would seemly miss a
useful application employing this approach.  It would also mean there would
be an extra 16 bit field created if a 32 bit CRC were used.

 -Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 7 May 2002 15:55:41 -0700

All again,

As yet another crazy idea, should UDP-Lite adopt 32-bit CRC (Hopefully
SCTP's and similarly  iSCSI's.), the extra 16-bit field could use the SCTP
multiplexor: Stream. ; )

  -Doug

On May 7, 2002 3:23 PM Douglas Otis ([email-masked]) wrote:
>
> All,
>
> There has been interest within the RDMA group to impose separate
> Header and Payload checks as a means to reduce the size of a FIFO
> to handle Payload placement.  Should there be a problem detected
> within the payload, the point in time where this is handled can
> be delayed provided Header information is known to be correct
> before hand.  This information deals with attributes such as
> Buffer ID, Offset, and Length.  The simple checksum proposed for
> UDP-Lite would not allow an adequate level of assurance for such
> use.  Why is such a weak level of checking being used?  This would
> seemly miss a useful application employing this approach.  It
> would also mean there would be an extra 16-bit field created if a
> 32-bit CRC were used.
>
>  -Doug
>
>
> > The IESG has received a request from the Transport Area Working
> > Group Working Group to consider The UDP Lite Protocol

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 7 May 2002 18:23:13 -0700

Follow-on:

Selective handling of unchecked UDP per stack or port where unchecked
'classic-UDP' would be consequently rejected if sent to a UDP-Lite enabled
port or application.  A stack or port option of not allowing unchecked UDP
except if UDP-Lite would be a means to ensure UDP handling is less confused
by the differing lengths.  The stack could make a validation exception based
on a Stream selection.  A negotiation protocol similar to RPC port mapper
could further enable other Streams once negotiations completed on Stream 0.

Default Classic UDP Header
 +--------+--------+--------+--------+
 |     Source      |   Destination   |
 |      Port       |      Port       |
 +--------+--------+--------+--------+
 |    Checksum     |                 |
 |    Coverage     | 16-bit Checksum |
 +--------+--------+--------+--------+
 /                                   /
 \            data bytes ...         \
 /                                   /
 +---------------- ...---------------+

Negotiated UDP-Lite Header:
 +--------+--------+--------+--------+
 |     Source      |   Destination   |
 |      Port       |      Port       |
 +--------+--------+--------+--------+
 |    Checksum     |                 |
 |    Coverage     |    Stream (0)   |
 +--------+--------+--------+--------+
 |              CRC-32c              |
 +--------+--------+--------+--------+
 /                                   /
 \            data bytes ...         \
 /                                   /
 +---------------- ...---------------+

When using 16-bit one-complement summation and the computed checksum is
zero,
it is transmitted as all ones (the equivalent in one's complement
arithmetic).
An all zero transmitted checksum value on a UDP-Lite enabled port means that
the transmitter generated a UDP-Lite Header with a CRC-32c checksum (for
higher level protocol error processing).  If the port or associated
application is not UDP-Lite enabled, then the packet may be passed
unqualified
to the application.  Applications should ensure ULPs communicate in
compatible
modes or a 32-bit CRC value may prepend data or data may be truncated.

A UDP-Lite enabled Stack SHOULD be differentiated at the port and
identifiable
to the application.  It may be problematic if intervening equipment rejects
UDP-Lite Streams.  In addition, any Stream other than Stream 0 may be
rejected
by a path.  The path and the port must be checked for compatibility.
UDP-Lite
may 'Slow Path' some IPv6 routers that normally reject unchecked (UDP-Lite)
packets.

 -Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 7 May 2002 22:39:46 -0700

Phillip,

The zero UDP checksum could be used as a mode selector.  Just as the current
UDP-Lite may run into path compatibilities of truncation negating complete
interchange, a complete loss of interchange may plague a 32-bit CRC scheme
for IPv6 or non-Stream 0.  The CRC field would provide positive confirmation
not otherwise apparent with the current proposal, however.

If it can be confirmed that the port is UDP-Lite enabled, then sending
Stream information should not cause any added state within the stack.  The
sending application would carry this burden.  The compatibilities would be
two fold.  1) This would not be immediately compatible with IPv6.  2)
Non-Stream 0 use may not be compatible with older IPv4 implementations
whereas a 32-bit CRC Stream 0 would.  Mandating use of a 16-bit Checksum of
0 prevents that problem.

I agree just a 16-bit checksum may be more compatible with current
implementations, if IPv6 is included.  An advantage in using CRC-32 is the
confirmation.  As either UDP-Lite proposal is suggesting a tweak, where is
the pain threshold?  Bumping up to a 32-bit CRC would provide for new uses.
A 16-CRC does not offer any additional compatibility with the loss of a mode
selector.  I would rather stick with a 16-bit Checksum of 0.  If IPv6
represents a low level of implementation, then a 32-bit CRC version may
offer a higher levels of compatibility.

It was just a thought.

 -Doug

On May 7, 2002 9:18 PM Phillip Conrad ([email-masked]) wrote:
>
> Doug,
>     I can see where going with a CRC (whether 16-bit or 32-bit)
> instead of a 16-bit classic-IP-style checksum (1's comp of 1's
> comp sum) would offer some additional error protection for the
> portion of a UDP-lite packet that we DO want to protect from
> errors.   That might be worth taking a look at, and weighing
> against the downsides of making such a change.
>
> However, one of the things I like about the current UDP-Lite
> proposal is its simplicity.   In that light, I am concerned
> about some of your other suggestions.... particularly,
> streams, and negotiation of multiple header formats.
>
> When you start "negotiating" anything (such as "header format
>(a) versus using header format (b)), then its my sense that the
> end systems will have to maintain state about which choices
> were made during the negotiation.  Now you are on the slippery
> slope towards needing connection orientation, acknowledgments,
> etc. (Considerations: How does each side "know" that the other
> side understands the options that are being sent and has
> successfully recorded the choices made?  Would we need some
> kind of 3 or 4 way handshake, with timeouts and acks, and
> retransmissions, etc. etc. etc.  ?!?!).
>
> My sense is that one of the baseline assumptions underlying the
> UDP-Lite approach is that, like UDP, UDP-Lite is a datagram
> protocol (i.e. stateless).    Each datagram needs to be a
> self-contained unit, relying on nothing outside the datagram
> itself for proper interpretation of that datagram (i.e., no
> prior state negotiation needed.)
>
> If you see a need for a partial-checksum, datagram-oriented
> transport protocol with a 16 or 32 bit CRC instead of a
> classic-IP-style checksum, then by all means, make the case
> for CRC vs. checksum.    My suggestion to you though is that
> your case will be more persuasive if it isn't wrapped up with
> these other issues of stream numbers, negotiation of multiple
> header formats, etc.    Perhaps I am missing something, but
> I'm not sure what problem these other fields are helping us
> to solve.  If it is just trying to find a way to use the
> leftover 16 bits, then perhaps it is better to (a) leave them
> reserved unless/until there is a very specific reason to do
> something else with them, or (b) try to make do with a 16-bit
> CRC so that the UDP-Lite header length can be kept to 8 bytes.
>
>
> Cheers,
> Phill
>
> PS: I don't usually have a "quote" in my signature, but I've been
> inspired to make an exception...
>
> ******************************************************************
> * "Tis a gift to be simple"  --- opening line of "Simple Gifts", by
> * Shaker Elder Joseph Brackett, Jr. (1848)
> ******************************************************************
>
> At 06:23 PM 5/7/2002 -0700, Douglas Otis wrote:
> > Follow-on:
> >
> > Selective handling of unchecked UDP per stack or port where
> > unchecked 'classic-UDP' would be consequently rejected if sent
> > to a UDP-Lite enabled port or application.  A stack or port
> > option of not allowing unchecked UDP except if UDP-Lite would
> > be a means to ensure UDP handling is less confused by the
> > differing lengths.  The stack could make a validation
> > exception based on a Stream selection.  A negotiation protocol
> > similar to RPC port mapper could further enable other Streams
> > once negotiations completed on Stream 0.
> >
> > When using 16-bit one-complement summation and the computed
> > checksum is zero, it is transmitted as all ones (the
> > equivalent in one's complement arithmetic). An all zero
> > transmitted checksum value on a UDP-Lite enabled port means
> > that the transmitter generated a UDP-Lite Header with a
> > CRC-32c checksum (for higher level protocol error processing).
> > If the port or associated application is not UDP-Lite enabled,
> > then the packet may be passed unqualified to the application.
> > Applications should ensure ULPs communicate in compatible
> > A UDP-Lite enabled Stack SHOULD be differentiated at the port
> > and identifiable to the application.  It may be problematic if
> > intervening equipment rejects UDP-Lite Streams.  In addition,
> > any Stream other than Stream 0 may be rejected by a path.  The
> > path and the port must be checked for compatibility. UDP-Lite
> > may 'Slow Path' some IPv6 routers that normally reject
> > unchecked (UDP-Lite) packets.
> >
> >  -Doug
> >
> > > > use.  Why is such a weak level of checking being used?  This
> > > > would seemly miss a useful application employing this approach.
> > > > It would also mean there would be an extra 16-bit field created
> > > > if a 32-bit CRC were used.
> > > >
> > > >  -Doug
> > > >
> > > >
> > > > > The IESG plans to make a decision in the next few weeks,
> > > > > and solicits final comments on this action.  Please send any
> > > > > comments to the [email-masked] or [email-masked] mailing lists
> > > > > by May 15, 2002.
> > > > >

---

From: Phillip Conrad <[email-masked]>
Date: Wed, 08 May 2002 00:17:36 -0400

Doug,
    I can see where going with a CRC (whether 16-bit or 32-bit) instead of a
16-bit classic-IP-style checksum (1's comp of 1's comp sum) would offer some
additional error protection for the portion of a UDP-lite packet that we DO
want to protect from errors.   That might be worth taking a look at, and
weighing against the downsides of making such a change.

However, one of the things I like about the current UDP-Lite proposal is its
simplicity.   In that light,
I am concerned about some of your other suggestions.... particularly,
streams, and negotiation of multiple header formats.

When you start "negotiating" anything (such as "header format (a) versus
using header format (b)), then its my sense that the end systems will have
to maintain state about which choices were made during the negotiation.
Now you are on the slippery slope towards needing connection orientation,
acknowledgments, etc. (Considerations: How does each side "know" that the
other side understands the options that are being sent and has successfully
recorded the choices made?  Would we need some kind of 3 or 4 way handshake,
with timeouts and acks, and retransmissions, etc. etc. etc.  ?!?!).

My sense is that one of the baseline assumptions underlying the UDP-Lite
approach is that, like UDP, UDP-Lite is a datagram protocol (i.e.
stateless).    Each datagram needs to be a self-contained unit, relying on
nothing outside the datagram itself for proper interpretation of that
datagram (i.e., no prior state negotiation needed.)

If you see a need for a partial-checksum, datagram-oriented transport
protocol with a 16 or 32 bit CRC instead of a classic-IP-style checksum,
then by all means, make the case for CRC vs. checksum.    My suggestion to
you though is that your case will be more persuasive if it isn't wrapped up
with these other issues of stream numbers, negotiation of multiple header
formats, etc.    Perhaps I am missing something, but I'm not sure what
problem these other fields are helping us to solve.  If it is just trying to
find a way to use the leftover 16 bits, then perhaps it is better to (a)
leave them reserved unless/until there is a very specific reason to do
something else with them, or (b) try to make do with a 16-bit CRC so that
the UDP-Lite header length can be kept to 8 bytes.

Cheers,
Phill

PS: I don't usually have a "quote" in my signature, but I've been inspired 
to make an exception...

*********************************************************************************
* "Tis a gift to be simple"  --- opening line of "Simple Gifts", by
*                                        Shaker Elder Joseph Brackett, Jr. 
(1848)
**********************************************************************************