Subject: RE: The problem with tagging packets

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Tue, 11 Nov 1997 10:51:07 +0200

On  10 Nov 97 at 2:41 PM, Jon Crowcroft wrote:

>>May any supporter of 1 DP bit explain how can the above TCP/IP problem   
be
>>solved with one DP bit?
>
>and how is it that {F}RED (without any bits) fails to solve this?

It may solve but it has some problems as well. Firstly, we need weighted   
RED for fair division of bandwidth between different type of users.   
Weights must be delivered to every node: that means a signaling system.   
Secondly, every node must measure every individual flow and calculate the   
drop preference level for every individual packet.

Certainly, you can do both operations, but in my mind, the use of 2   
additional bits (which are already available in the IP header) is quite   
small cost compared with the advantages. We shall, especially,  consider   
the scalability issues, for instance, how do different scenarios work in   
case of a backbone network based on 40 Gbit/s ATM crossconnects.

.. Kalevi

---

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Tue, 11 Nov 1997 12:47:57 +0200

As Alessio Casati writes in the attached mail, there there are some   
proposals based on TCP profiles.

But for me "some information will be propagated back to the access" is   
too similar to ABR: it means some kind of signalling, it means that every   
node must determine (how?) whether every flow is behaving properly, and   
it even means that the node must know whether a flow is using tcp or some   
other protocol.

At least I want a solution that (among other things):

* works as well with tcp, udp or any other protocol,
* makes possible to divide the available network capacity proportional to   
some pre-defined weights, so that by paying more you get a bigger amount   
of network capacity, and
* does not need any new or old signalling system to propagate information   
about the current load state in the network.

You may, of course, have other targets, but anyway, a system based on TCP   
profiles hardly can meet my targets.

.. Kalevi

 ----------
From:  Alessio Casati
Sent:  10. Novemberta 1997 4:41 PM

..

For fairness reasons I must now tell you how you can solve it with 1 bit   
DP and
a profile meter. Let us suppose Guy A wants a FCS (First Class Service)   
TCP service. A goes to his provider (ISPA) an tells he wants that. ISPA   
is happy he got a
new customer and asks him what's the per connection profile he feels more   
comfortable with (IETF guys have been able to find workable TCP service   
profile, some early proposal exists in Clark/Wroclawski draft). A choses   
its own profile and back he goes.When using such a service, A's behaviour   
will be metered by some ISPA's access profile meter. If A is a bad guy   
the meter will detect it. And mark (or discard, if A is too bad) all the   
traffic exceeding the profile. The network will deliver bad packets IFF

 - enough resouces are available.
 - Drop statistics don't identify A as a too bad guy, in such a case some
information will be propagated back to the access to enforce drop at the   
ingress (this is not ABR, it's bad guys penalty).

That'my point of view. To be fair the hardest point is how to define a   
TCP
profile and coping with the extension of the required service.
The advantage is very simple network behaviour and complexity at the   
access
(that's the way the internet has scaled up to date).
Yes, some overprovisioning is likely to occur, if we want to provide FCS   
this
way. But I don't think multiple DP will avoid it.

Waiting for your detailed explanation.

Alessio

---

From: [email-masked]
Date: Tue, 11 Nov 97 10:23:38 PST

On 11 Nov 97 at 13:55, Juha Heinanen wrote:

> i'm asking this on this list the third time already:  how can one
> identify flows in encrypted in packets?

Juha,

Why isn't the mechanism adopted by RSVP (see RFC 2207) an adequate
solution?  It uses the SPI for classification.  [There are some
limitations for shared reservations, documented in the RFC, but
shared reservations probably don't make much sense for encrypted
streams].

Bob Braden

---

From: Ed Ellesson <[email-masked]>
Date: Thu, 13 Nov 1997 16:19:54 -0500

Bob, 

At 10:23 AM 11/11/97 PST, [email-masked] wrote:

>streams].

<bigger>You brought up using the SPI field as a means of indicating
queuing and/or drop preference.  I think using the SPI field works for
RSVP, because you can signal the SPI that is being used for the session
you want to reserve traffic for.  However, without RSVP (or YASP) to
signal, I don't think using the SPI works for this purpose, for the
following reasons:  

(IPSEC experts, please keep my honest here!)

1. It is my understanding that the SPI value is newly established for
every security association.  Trying to correlate the assignment of SPI's
to a set of dropping and/or queuing precedence levels, which are, in
turn, mapped to traffic types, would be a tough administrative problem,
in my opinion.   

2. Using the SPI requires that the device and software module that
encrypts or authenticates must also have knowledge of the precedence
level, in order to choose an SPI that indicates the proper delay
preference to the network.  

3. Multiple security associations would have to be created between any
two encryption/decryption pairs, in order to handle the multiple traffic
types (delay preferences) that flow between them, whereas only one
security association may otherwise suffice between any two entities.  

4. A very realistic scenario for IPSEC involves encrypting in end
systems, with additional authentication in firewalls at the edge of the
Internet.  The firewalls have their own security associations
(firewall-to-firewall)  that appear in their SPI's.  In other words,
tunnels within tunnels.  I don't even want to think about trying to get
the routers along the way to figure out which SPI's to look at to get the
right precedence level, while keeping their policy cache up-to-date with
the right SPI-to-precedence level mapping.    

Using the TOS octet, instead of the SPI, to indicate delay preference, 
avoids all these disadvantages, unless I missed something.  

</bigger>

Regards, 

Ed Ellesson

Sr. Engineer, TCP/IP Technology Management

IBM Networking Software Products

Research Triangle Park, NC 

[email-masked]

919-254-4115