Subject: Fuzzy-layering and its suggestion

From: "Jason Gao" <[email-masked]>
Date: Thu, 5 Sep 2002 21:11:06 +0800

Fuzzy layering is not a new philosophy of protocol design.

In IP hourglass model the IP layer lies between the upper transport layer and the lower physical network layer, hides the details of various access methods of the physical media and/or the different physical media themselves.

There is an observation that the IP layer, the transport layer protocol TCP/UDP and the de facto API suite, which we may call application adaptation layer, BSD Socket are actually not strictly layered but instead interleaved to a certain extent.

Meanwhile, the application layer is strictly non-interleaved with the physical network layer.

We can call this phenomenon ‘fuzzy-layering’. Layering to some extent do help, yet interleaving among layers, limited to a certain extent, is beneficial, even inevitable. Meanwhile, no layering at all is thoroughly unimaginable. The extent is, IMHO, three clear layers, each layer with some interleaved sub-layers. The three layers are the application layer, the grand transport layer, and the physical network layer. The grand transport layer consists of three sub-layer: network (sub-)layer (IPv4/IPv6), transmission (sub-)layer (UDP/TCP/SCTP), some shim (sub-)layers (TLS, RTP etc.) and the application adaptation (sub-)layer (BSD Socket, OpenSSL, etc.).

Fuzzy-layering tells us that transport layer protocol and network layer protocol may share some bit field in the network layer protocol header.

--- 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.

--- Traffic classifier

Let a bit in the Traffic Class octet of the IPv6 header be 'Milk Type Indicator' (MTI, but not' moving target indicator'), which means to request timely delivery of a packet.

The transport layer of the sender may set the bit, which tells the intermediate network layer devices to queue the packet 'first in first drop'. That is, the router should queue a packet with MTI bit set in a short, fast queue. When the queue overflows, the router drops the oldest packet at first.

The receiving side of the transport layer may deliver to the upper layer application the packets with MTI bit set in the preserved send order, while discard those packets delayed longer than some negotiated constraint.

In fact the MTI bit is a 'two-class', one class is 'wine type', the other is 'milk type', QoS classifier. It is a class of classifier different from priority.

--- IPv6 flow label assignment

Transport layer may set a 'control' bit in the IPv6 Traffic Class octet of the initiating packet during the setup phase of a connection.

The edge router inspects the control bit. If it is set, the edge router can further inspect the packet, and reserve resource as required by the piggybacked resource reservation header in the transport layer packet, allocate and/or assign a flow label to the expected connection, put the flow label in the flow label field of the initiating acknowledgement packet.

When the transport layer try to tear down a connection gracefully it should set the same control bit in the Traffic Class octet as well. The edge router should release the flow label and corresponding reserved resource. Of course a time-out mechanism should also be applied to recycle flow labels.

If a site has multiple edge routers, the routers can be configured as a functional cluster that shares the same flow label space.

--- Mobility, the split of the interface ID of the IPv6 header

We can split the 64-bit interface ID into two 32-bit parts. The higher 32-bit could be called ‘host aggregation ID’, the lower 32-bit could be called ‘upper layer thread ID’.

When an endpoint is roaming, the 96-bit prefix of its IPv6 address may vary at different access points, but the upper layer thread ID should be kept. The endpoint should notify its peer when its IPv6 address is changed. The peer should send packet to the endpoint in the new address. In the context of the endpoint the upper layer thread ID must be unique and thus the connection is kept across varying IP address. Of course, message authentication code should be applied to support the identification of the connected peers, and optionally to protect the integrity of the message.

---

From: Fred Baker <[email-masked]>
Date: Thu, 05 Sep 2002 13:58:08 -0700

>TCP in the end system and IP in the intermediate systems share the two ECN 

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.

---

From: "Jason Gao" <[email-masked]>
Date: Fri, 6 Sep 2002 09:00:44 +0800

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.

---

From: "vinton g. cerf" <[email-masked]>
Date: Fri, 06 Sep 2002 00:30:57 -0400

this was a choice made long ago to increase by a small amount the efficiency of the representation of the two layers. Keep in mind that IP was split off of TCP in version 3 of the protocol. They were originally combined.

vint cerf

>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) co…

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

---

From: "Jason Gao" <[email-masked]>
Date: Fri, 6 Sep 2002 13:15:25 +0800

Thanks for the comment!

I didn't mean to blaim that TCP and IP is not 'clear' ( I should have used the word 'stern', or some other word not so commendatory as 'clear') layered. What I really wanted to say is that I prefer the choice, because I think it is a positive example of fuzzy-layering.

Thanks for the comment again!

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 6 Sep 2002 00:35:15 -0500

Attempts to redefine the IPv4 Header to block clear paths to using all 160 bits in the IPv4 Header
for extended addressing and routing have been political in nature, not technical. With 128-bit DNS,
more bits in the 160 bit IPv4 Header are available for setting and for extended addressing and
routing. Because of the dominance of UDP and TCP in the next layer, the 16-bit Port number also
becomes part of the available extended addressing, or sub-addressing. The current "public IPv4"
non-QoS transport is defined at the edges by operators willing to provide clear-channel 160-bit clean
transport from one side to the other, with the awful overhead of checksum changing and the less
than optimum routing paths. Native IPv4++, using all of the extended addressing, can evolve and
grow around the edges of that legacy core. Native IPv4++ will of course benefit from higher-speed
(more optimal) direct routing, and can use the legacy core as a last resort to getting packets from
one place to another. Keep in mind that equipment vendors claim that 80% of all IPv4 equipment
never connects directly to that legacy core. When one looks at the ethically bankrupt people who
operate that legacy core, one wonders why anyone would want to touch it with a 10 ft. cable.
....route around it.....

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

----- Original Message -----
From: "Jason Gao" <[email-masked]>
To: "Fred Baker" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 05, 2002 8:00 PM
Subject: Re: Fuzzy-layering and its suggestion

> 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.

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 6 Sep 2002 00:50:55 -0500

Legacy systems always have some ugly limitations that people have to work around.
Look at the Intel x86 processor architecture with the evolution of segmented addressing
compared to the 68000, SPARC or PowerPC which people claimed would clearly
replace the ugly x86 because of the more modern, clean, massive virtual memory
address architecture and clean RISC instruction set decoding...

....when is the wide-spread replacement for the x86/Pentium scheduled ?
When is the year of the C@t ?
http://www.ddj.com/articles/1993/9310/
http://maccentral.macworld.com/news/0208/25.jaguar.php

Jim Fleming

----- Original Message -----
From: "Jason Gao" <[email-masked]>
To: "vinton g. cerf" <[email-masked]>; "Fred Baker" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 06, 2002 12:15 AM
Subject: Re: Fuzzy-layering and its suggestion

> Thanks for the comment!
>
> I didn't mean to blaim that TCP and IP is not 'clear' ( I should have used the word 'stern', or some other word not so
commendatory as 'clear') layered. What I really wanted to say is that I prefer the choice, because I think it is a positive example
of fuzzy-layering.
> > this was a choice made long ago to increase by a small amount the efficiency of the representation of the two layers. Keep in
mind that IP was split off of TCP in version 3 of the protocol. They were originally combined.

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 6 Sep 2002 01:03:54 -0500

----- Original Message ----- 
From: "Fred Baker" <[email-masked]>
To: "Jason Gao" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 05, 2002 3:58 PM
Subject: Re: Fuzzy-layering and its suggestion

Attempts to redefine the IPv4 Header to block clear paths to using all 160 bits in the IPv4 Header
for extended addressing and routing have been political in nature, not technical.

All 8-bits of the TOS field are available for routing. There are no ECN bits. Look in the code.
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=tos+routing

The 8-bit TOS field can be split into two 4-bit fields to add 4 extended addressing bits to
the 32-bit addressing. You might view this as saying all one-story buildings now have 15
more floors above them for expansion. Yes, there are special attributes about the cases
where TOS=0*x or *0x, but those are easy to note and handle as the transition is made.

Jim Fleming

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Sep 2002 10:39:09 +0200

Jason Gao wrote:
...
> The edge router inspects the control bit. If it is set, the edge router can further inspect the
> packet, and reserve resource as required by the piggybacked resource reservation header in the
> transport layer packet, allocate and/or assign a flow label to the expected connection, put the flow
> label in the flow label field of the initiating acknowledgement packet.

No. There is no such usage of the traffic class octet. See RFC 2474.
Also, only the source host of a packet may set the flow label.
See draft-ietf-ipv6-flow-label-03.txt

   Brian

---

From: "Jason Gao" <[email-masked]>
Date: Mon, 9 Sep 2002 18:07:02 +0800

> See draft-ietf-ipv6-flow-label-03.txt
Well, both the draft and RFC 2474 are not the final standard. And both the traffic class octet and the flow label field are subject to further discuss. So I didn't mean to prove fuzzy-layering by the fields in IPv6 but instead tried to make some suggestions for the development of IPv6 in the QoS domain, according to the fuzzy-layering practices.

Anyway, thanks for the comment!

Jason

---

From: "Jason Gao" <[email-masked]>
Date: Mon, 9 Sep 2002 18:10:18 +0800

Jason

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Sep 2002 14:21:35 +0200

Jason Gao wrote:
> Well, both the draft and RFC 2474 are not the final standard. 

RFC 2474 is a Proposed Standard, which means that fundamental
changes are extremely unlikely. The flow label draft is indeed
still a draft, but there is very strong WG consensus that flow
labels must be immutable.

> And both the traffic class octet and the flow label field are subject to further discuss.

If you are referring to the text in RFC 2460, the traffic class is 
definitively specified by RFC 2474. The flow label draft is intended 
to be definitive, as soon as it's agreed.

   Brian

---

From: "Jason Gao" <[email-masked]>
Date: Tue, 10 Sep 2002 09:21:40 +0800

> labels must be immutable.

draft-ietf-ipv6-flow-label-02.txt didn't specify a signaling protocol for the host /end-system and the router / intermediate system to negotiate / assign flow label. The draft said:

"

The assignment of a packet to a flow takes various forms, presented

   below:

   (1)  The source MAY take part in a signaling protocol that results in

        assigning certain transport connection(s) or application data

        stream(s) to specific flow(s).

   (2)  The source MAY be configured to assign certain transport

        connection(s) or application data stream(s) to specific flow(s).

   (3)  The source SHOULD assign each new application data stream (e.g.

        RTP streams) to a new flow.

   (4)  The source SHOULD assign each new transport connection (e.g.

        TCP, SCTP) to a new flow. 

"

As:

--- Yet no standard signaling protocol exists to negotiate the flow label.

--- If end nodes behave as (3) and (4) require, each new application data stream or new transport connection should need a new flow, it is very likely that before or along with the negotiation of a new transport connection, end nodes also take part in a process of negotiating new flow label, if a signaling protocol is used.

And if we apply fuzzy-layering practices, we may find it is quite convenient to piggy-back the flow-label negotiation signals on the negotiation packets during the setup phase of the transport connection.

We can still require that the flow labels must be immutable after the connection is successfully setup.

> to be definitive, as soon as it's agreed.
RFC 2474 not only left two pools of codepoint space for experimental / local use but also left the code point number in the pool of 'standards action' unassigned. So I don't think it is definitive. I mean it did not prohibit the use of one bit in the traffic class octet for control purpose.

Jason.

---

From: Fred Baker <[email-masked]>
Date: Mon, 09 Sep 2002 19:23:55 -0700

At 09:21 AM 9/10/2002 +0800, Jason Gao wrote:
>I mean it did not prohibit the use of one bit in the traffic class octet 
>for control purpose.

actually, it very explicitly did. At the top of page 8, it says:

    Implementors should note that the DSCP field is six bits wide.  DS-
    compliant nodes MUST select PHBs by matching against the entire 6-bit
    DSCP field, e.g., by treating the value of the field as a table index
    which is used to select a particular packet handling mechanism which
    has been implemented in that device.

The other two bits are defined by RFC 3168.

You don't get to pull a bit out for your private use.

---

From: "Jason Gao" <[email-masked]>
Date: Tue, 10 Sep 2002 12:46:43 +0800

> You don't get to pull a bit out for your private use.
It is still not a requirement that every node in the Internet must be DS-compliant.

Jason

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Sep 2002 16:57:32 +0200

Jason,

As co-chair of the diffserv WG, and co-author of the flow label draft,
I assure you that your interpretation is incorrect in both cases.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Sep 2002 16:59:12 +0200

Jason Gao wrote:
...
> It is still not a requirement that every node in the Internet must be DS-compliant.

These statements are both true. A node that chooses not to
implement RFC 2474 cannot use the TOS bits for private purposes.

   Brian

---

From: "Jim Fleming" <[email-masked]>
Date: Tue, 10 Sep 2002 19:20:37 -0500

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Jason Gao" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 10, 2002 9:59 AM
Subject: Re: Fuzzy-layering and its suggestion - Towards better QoS solution in the IPv6 network

> implement RFC 2474 cannot use the TOS bits for private purposes.

You seem to be confused about how the 32-bit, IPv4, end-to-end, Internet is defined.
You seem to be focused on nodes outside of the Internet, as opposed to the infrastructure
that creates what most people view as "the Internet".

From a user's point-of-view, the edge of the global, public, 32-bit, IPv4++ Internet
is defined as the collection of private companies and people, connected together, that
pass 160-bit headers with the **8-bit TOS field unchanged**. Those 8-bits can be used
to expand the addressing at the edges of that network, 4-bits are needed in each direction.
That expands the address space by adding 15 more Internets, as large as the legacy net.
That creates yet another layer or edge, composed of equipment that combines to make
people see 4 extended address bits, for a total of 36.

You can easily obtain code to do this, or help write more code to do it.

http://www.netfilter.org/
http://netfilter.samba.org
http://www.google.com/search?q=TOS+routing
http://www.google.com/search?q=packet+mangling

As for IPv6, one can not assume that the 128-bit DNS implies IPv6. As an example,
if you use a 2002 model year address, such as 2002:[IPv4]:* in the 128-bit DNS AAAA
records, your computer will likely generate IPv4 packet headers. A6 DNS records are
for IPv6. AAAA records work for IPv4++. Private companies and private individuals
are working together to define what goes in the AAAA records. You are FREE to
participate. Some private companies and closed societies may try to tell you that you are
not free to participate, but that is not the case. Even with tens of millions of dollars from
domain name sales and address space leasing, they will not be able to pull together enough
money to buy the freedom of all people on planet Earth. They may try...but, most people's
minds are not for sale.

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: "Jason Gao" <[email-masked]>
Date: Wed, 11 Sep 2002 10:27:41 +0800

Thanks for the comment, but as both an end user and a programmer I am not satisfied with the diffserv standard (primarily implemented in the IPv4 network) and the IPv6 flow-label draft  proposal to solve the QoS issue in the Internet. As far as I know, it seems that QoS is the Achilles' heel of the IPv4 Internet, though diffserv (or intserv) has been proposed for quite a long time (in the Internet time). (As to the flow label, Mr. Atkinson has made me have to believe that it has no presently clear usefulness yet.)

The IPv6 Internet has the potential to change the impression that the Internet is only able to provide best-of-effort class of service. Presently in the IPv4 internet to assure high QoS one usually throw more bandwidth to the upper layer applications, presuming there will be no network congestion. In corporate network, with support of so-called multi-layer switches, it is a feasible solution. In the large Internet, it seems not.

I mean we cannot just take for granted that the QoS model of the IPv6 Internet should be the same as the IPv4 network. The traffic class bits of the IPv6 header is not necessarily defined identical with the ToS bits of the IP4 header. It is really my private idea, but it is not a private issue.

Jason.