Application knowledge of transport characteristics (was: Re: Domain Cent

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf