----- Original Message ----- From: "Dave Crocker" <dhc2@xxxxxxxxxxxx> To: "Ned Freed" <ned.freed@xxxxxxxxxxx> Cc: <ietf@xxxxxxxx> 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf