Subject: [PWE3] [Fwd: Guidelines for protocol designers using UDP]

From: Stewart Bryant <[email-masked]>
Date: Thu, 27 Sep 2007 12:50:30 +0100

We specify TDM over UDP and so should look at this.

Yaakov - is this something that we should request be liaised to SG13?

- Stewart

Subject: Guidelines for protocol designers using UDP
From: Magnus Westerlund <[email-masked]>
To: Internet Area <[email-masked]>, [email-masked], [email-masked], [email-masked], SAAG <[email-masked]>
Cc: tsvwg <[email-masked]>
Date: Thu, 27 Sep 2007 13:33:30 +0200
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>

Hi,

In the TSVWG we have been developing a guidelines document for UDP. It
is intended for protocol designers that consider using UDP in their
protocol. We do hope that it will help remove some of the misconception
that UDP is a simple protocol to use. It might look that way because
most of the features necessary for being acceptable to deploy on the
general internet needs to be specified by the one using UDP. It is also
something that the Transport ADs already started using as help in
explaining why and what to fix when we put a DISCUSS on your document
that is using UDP.

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-03.txt

So TSVWG is still working on this document but we are now considering it
quite complete. So we are looking for feedback from you. Are there
things that are unclear, missing, wrong, etc. Please provide your
feedback to TSVWG ([email-masked]).

Thanks

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

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

---

From: <[email-masked]>
Date: Thu, 27 Sep 2007 14:03:43 +0100

Stewart wrote 27 September 2007 12:51

> Yaakov - is this something that we should request be liaised to SG13?

Please excuse me jumping in on this.....

I think a key point that some folks might miss here is the fact that all
applications can be classified as either message, file or stream
information sources.  Further, since networks (any mode) can introduce
impairments (errors/loss/timing/misordering - the degree of impairment
depends on the mode) it is usual to encode the application's traffic
units (ie add further information) in such a way that provides some
mitigation of the expected level of impairments that the network might
introduce.  

In IP we have the general classification of message=>UDP, file=>TCP and
stream=>RTP(overUDP).  The added information is usually:
-	an error/integrity check for messages
-	to which we add a sequence check for the ordered set of messages
that make up files
-	or we add a time-stamp check for the ordered set of messages
that make up streams.

ATM has similar encodings in the so-called AALs.  

In functional architecture terms the above are what I would call
'end-system application to 1st layer network adaptation functions'.  In
other words, they are specifically designed to interface with a given
end-system application and NOT higher layer networks, ie they were not
designed for this.  There are, of course, adaptation functions between
layer networks when these form a client/server relationship.  However,
these adaptations functions are quite different.....and although owned
by the server layer their precise specification is a function of both
the server layer mode and the client layer mode.  A key factor here is
that these inter-layer client/server adaptation functions do not support
a single end-system application but usually are required to support a
time-varying aggregate/mix of end-system applications....which in
practice can be several layer networks removed (going upwards through
the stack).

So, IMO carrying a co-cs mode TDM layer network (such as the layer
networks found in the PDH or SDH) over UDP (which BTW is not a layer
network anyway) is a misuse of UDP.  Well, that's my opinion anyway.

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 30 Sep 2007 10:43:01 +0200

> Yaakov - is this something that we should request be liaised to SG13?

Stewart, 

This document is certainly interesting, but does not directly address
our kind of application.

When sending TDM over UDP/IP the rate CAN NOT be reduced without
serious service disruption, but on the other hand, the service
DOES NOT increase in bandwidth over time, nor does it have 
momentary peaks of high bandwidth usage.

Thus the recommendations are mostly irrelevant
(there is no way of backing off the rate except disrupting the service)
but the impact is not serious (since the TDM over UDP/IP will
not increase in rate to capture the bandwidth given up by 
falling back TCP flows).

Perhaps we should liaise the TSVWG first ...

Y(J)S

---

From: Danny McPherson <[email-masked]>
Date: Sun, 30 Sep 2007 11:18:08 -0600

> not increase in rate to capture the bandwidth given up by

Given that we've got Standard Track work that does
carry TDM traffic over UDP, I think that's all the more
reason that concerned parties should provide feedback
on this document.

By the same token, ensuring that we can expand the
work in the UDP guidelines document to broader use
cases is surely of value as well.

-danny