Well, I should have cited another instance. What the TCP checksum protects
includes the pseudu-header which contains the source and the destination IP
address. Transport address in TCP (and SCTP) contains IP address. Clearly the
IP address is not stored in the transport layer header. IMHO it is not an
instance of clear layering.
Implementations that let TCP and IP 'share' the ECN bits, in another word,
practice in fuzzy-layering way, avoid the standardization process of the API
(actually there seems no standard, or de facto standard API that the IP layer
provides to the transport layer.), benefit from lower overhead accross layer
interface calls. Though 'fuzzy-layering' is really not a requirement, concerns
on performance and efficiency often make it the preferred practice principle.
----- Original Message -----
From: "Fred Baker" <fred(_at_)cisco(_dot_)com>
To: "Jason Gao" <jag(_at_)kinet(_dot_)com(_dot_)cn>
Sent: Friday, September 06, 2002 4:58 AM
Subject: Re: Fuzzy-layering and its suggestion
At 09:11 PM 9/5/2002 +0800, Jason Gao wrote:
--- TCP with ECN extension
has already been a practice of fuzzy-layering.
TCP in the end system and IP in the intermediate systems share the two ECN
bits in the IP header.
that is incorrect. First off, IP also is found in the end system, and uses
the ECN bits.
More important, though, is that TCP uses an IP service, through an
IP-provided API. The TCPs negotiate whether they are willing to run ECN,
and if they agree, they (on transmission) use the API feature that says
"please tell my peer if this datagram experiences congestion", and (on
reception) use the API feature that says whether or not congestion was
experienced somewhere in the network. All other communication regarding ECN
is via the transport header. SCTP also has a defined facility for the
transport exchange relevant to ECN.
If your implementation delivers the IP header to or from TCP or SCTP, then
the implementation of the API in question is the passage of that header. I
know of a number of implementations that do that; it certainly is a
convenient approach. However, I don't see any requirement that the API take
that form, and I know some very common implementations that don't.
I don't see any significant difference between using a service of this
type, and using a service that says "please send this message as urgent
data" to TCP, or "please send this message with this DSCP" to IP, or
"please send this message without permitting fragmentation" to IP. It's
just a service accessed through the API.