Re: PROs/CONs of SIP/PIP/TUBA

John Day <Day@bbn.com> Mon, 17 May 1993 16:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00451; 17 May 93 12:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00447; 17 May 93 12:14 EDT
Received: from p.lanl.gov by CNRI.Reston.VA.US id aa07279; 17 May 93 12:14 EDT
Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA21306; Mon, 17 May 93 10:09:16 -0600
Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA12106; Mon, 17 May 93 10:08:44 MDT
Return-Path: <day@BBN.COM>
Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA12102; Mon, 17 May 93 10:08:43 MDT
Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA21227; Mon, 17 May 93 10:08:42 -0600
Message-Id: <9305171608.AA21227@p.lanl.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Day <Day@bbn.com>
Subject: Re: PROs/CONs of SIP/PIP/TUBA
To: deering@parc.xerox.com
Cc: Day@p.lanl.gov, pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov
In-Reply-To: <93May17.081244pdt.12171@skylark.parc.xerox.com>
Date: Mon, 17 May 93 12:10:03 EST
Mail-System-Version: <BBN/MacEMail_v1.5@BBN.COM>

And he writes again:

>John Day wrote:
>
>>                             The IPAE properties that create the kind of
>> chaos found in some European phone systems where the number you are
>> calling depends on where you are calling from (and I don't mean just
>> more numbers added on the front; different numbers added on the front
>> depending on where you are calling from) is not something we want to
>> foist on the world.
>
>That is not a property of IPAE.  If it is possible for someone to come to
>so false a conclusion after reading the IPAE specification, we clearly need
>to work more on that specification.
>
While I could be wrong from my last reading of IPAE, if I move my end
system from one place to another all of the addresses I used to connect
to will have changed.  Why else are they exploring these methods to
download addresses?
>
>> Different addresses at the same place are really means for
>> distinguishing different types of flows. If you take this view you won't
>> believe the options you can get rid of. For example, priority is simply
>> a flow with different traffic characteristics and should be on a
>> separate address.
>
>That would work fine for connection-oriented priority, where the mappings
>from address to priority can be pre-established in the routers along a path.
>If your protocol supports connectionless priority (e.g., "loss preference"
>for layered video encodings) you don't want to have each of your routers
>doing some sort of directory lookup on each packet's destination address in
>order to determine the priority of the packet -- you want well-known priority
>values as a separate field (or in a fixed, known location within the address,
>which is effectively the same as a separate field).
>
Sorry Steve, but connection-oriented or not, pdus with different
priorities are simply different flows.  I realize that this is a shift
in frame of reference in how we normally think about things and that
such shifts are hard to think about.  Doing the routing does not require
doing a directory lookup for each packet's destination address (or only
if you look at the problem wrong).  The router merely has to know how it
treats which flows which are identified by their addresses. What you
want to know is what QoS policies are associated with which flows.  You
are making this problem too difficult.

Take care 
John