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. 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf