Application knowledge of transport characteristics (was: Re: Domain Centric Administration)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]