----- Original Message -----
From: "Dave Crocker" <dhc2(_at_)dcrocker(_dot_)net>
To: "Ned Freed" <ned(_dot_)freed(_at_)mrochek(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, July 03, 2007 7:08 PM
Subject: Application knowledge of transport characteristics (was: Re: Domain
Centric Administration)
Ned Freed wrote:
Keith, while I agree with your general point that applications have no
choice
but to be aware of lower layer semantics in many if not most cases, this
last
is not a good example of that. There is really no difficulty running SMTP or
any other stream oriented protocol on top of a record-based protocol - all
you
have to do is ignore the record boundaries and make sure your buffer isn't
larger than the maximum record size.
...
The converse is not true, however - you cannot simply slap a protocol that
depends on record boundaries onto a stream protocol and expect it to work,
such
as MAIL-11 over TCP (not that anyone in their right mind would use MAIL-11
this
way...).
I believe this highlights a basic opportunity (need) for the protocol
engineering community. Although it applies to any discussion about the
relationship between layer n and layer n+1 (or, layer n and layer n-1, if you
want to focus on the upper layer...), it seems to come up most often in
relation to application/transport discussions:
How can we discuss the essential services required of the lower layer,
without worrying about the means by which those services are delivered? That
is, how do we discuss the what, without discussing the how?
Related to that is discussion about lower layer services that supply more
than is needed, but still suffice.
Your example of record boundaries is useful because TCP's lack of the
construct used to cause all sorts of problems and hacks.
And perhaps still does. SNMP and syslog work fine over UDP but both have had to
introduce a 'hack' to work over TCP (as seen in isms and syslog-tls
respectively). netconf, which has never known UDP but would have been well
suited to it, also has a 'hack'.
But I see the converse too. TLS defines what it needs of a transport layer and
TCP provides it (and more); UDP does not so DTLS introduces a shim to add some
(but not all) of TCP's features to UDP.
If we had a range of transports (perhaps like OSI offered), we could choose the
one most suited. We don't, we only have two, so it may become a choice of one
with a hack. But then that limited choice may be the reason why the Internet
Protocol Suite has become the suite of choice for most:-)
Tom Petch
Another is in the
realm of "performance" characteristics. The need for predictable inter-packet
times for real-time voice or video streams highlight TCP's limitations. I've
also noted that applications developed for LAN environments rarely translate
well to WAN environments, due to implicit requirements for low latency and
high reliability. Conversely, applications designed for WAN environments tend
to work fine on LANs. (However I'm told there was quite a debate about
whether to tailor TCP to work differently on LANs, when LANs started to get
popular; thank goodness uniformity/simplicity arguments won out over local
optimization arguments.
The few times we've seen transport folks make efforts to solicit requirements
or issues comments from the application protocols community, the responses
have tended to be more along the lines of criticizing or recommending
particular protocol features.
It seems that we lack a vocabulary for discussing service needs, without
diving into protocol details. Yet upper-layer independence of lower-layer
details requires exactly that vocabulary.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf