Subject: RE: [arch-d] Name this concept

From: "Bound, Jim" <[email-masked]>
Date: Wed, 1 Mar 2006 07:41:43 -0500

On GSE 8+8.  I think met morphing the concept for discussion is good as
it was is probably long debate down long black tube.  This is probably a
whacky idea but I throw it out.

The low order 64bits of IPv6 address are pretty much now the End User
Identifier (EUI) and we are not going to use it in most address formats
for anything else it appears today.  

Would we be able to determine a means to use the EUI as location
identifier for when required (that is TBD) and also as seed to an
IP-session-ID (I am making up this term to avoid ever being connected to
the OSI session layer feel free to change it but I think we need to make
that clear unless we have dissent on god no OSI session layer).

The Fred issue that it is a number I think is ok if it is part of the
address and the IP-Session-ID does not have to be a number and could be
indirect pointer the EUI.

One problem to deal with is that there are some parts of the market that
are going to mandate use of IPv6 address use of RFC 3041 (whack the EUI
periodically so it changes and it cannot be tracked on the net - and
3041 has draft-biz update in process too).  Thus assuming any permanent
EUI is not good assumption.  Probably true for IP-Session-ID too.

This could also have a seamless transition that is backwards compatible.

/jim

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 1 Mar 2006 12:29:13 -0500

I know of two customers using it for multipath and its new features of
failover and record boundaries for multiple messages over SCTP so I
believe Randy's initial design center is in fact in tact and I did work
with Randy on this from the beginning as supporter and still am
supporter.  Have reviewed and seen 3 IP Stack implementations and with
all the diffs each was still able to do the multipathing.  Agree we need
to do architecture first so suggest taking the SCTP core principles and
extrapolating to the architecture need, which would avoid mixing
engineering initially.  But, before we say the architecture is good it
required engineering reality verification in some form.

/jim 

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]] 
> Sent: Wednesday, March 01, 2006 10:27 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Bound, Jim
> Subject: Re: [arch-d] Name this concept
> 
> This brings up a point I wanted to make against Jim's 
> original post on 
> SCTP, I think: engineering considerations may mess up the 
> architectural 
> concept. Randy Stewart originally intended SCTP to use all 
> its paths at 
> once. But, it's my impression, eventually active usage was 
> limited to a 
> single path at a time because our congestion adaptation models don't 
> tell us how to handle congestion across multiple inhomogeneous paths.
> 
> [email-masked] wrote:
> > John,
> >...
> > 
> > If these connections are using different link-layers, there might be
> > very different RTT, latency, packet loss, etc. for these 
> paths, and that
> > surely will effect the overall session.  I think we're 
> already finding
> > issues when running apps with various small devices over 
> cellular & wifi
> > radios, for example.  
> > 
> > For example, I don't think we have a good understanding of 
> all of the
> > issues when running traditional TCP congestion control over 
> the myriad
> > moblity solutions & extensions that the IETF is working on. 
>  This begs
> > the question, should TCP-bis congestion be re-worked?
> > 
> > John Loughney
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 3 Mar 2006 12:13:36 -0500

I believe at the transport.
/jim 

> From: Tony Li [mailto:[email-masked]] 
> Sent: Thursday, March 02, 2006 3:10 PM
> To: Fred Baker
> Cc: John Leslie; [email-masked]; Bound, Jim
> Subject: Re: [arch-d] Re: Name this concept
> 
> 
> Fred,
> 
> Do we want this flexibility in the transport protocol?  Or 
> should it be
> in a lower layer?
> 
> Tony
> 
> 
> Fred Baker wrote:
> > for the record, I was postulating TCP as we know it today, 
> but with at
> > least one (announce-address) and perhaps two (withdraw-address) new
> > options. The comment about "reliable receipt" presumed the
> > acknowledgment of a TCP segment that contained such an option.
> > 
> > As you say, the details of TCP are engineering more than 
> architecture.
> > As you otherwise noted, I think SCTP is a good thing, but I 
> don't see a
> > need to discard TCP. I do see a need to change it in some 
> way similar to
> > this.
> > 
> > On Mar 1, 2006, at 2:16 AM, John Leslie wrote:
> > 
> >>  Fred certainly doesn't mean TCP-as-we-know-it-today; but it might
> >> be better to say "TCP-bis"...
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 3 Mar 2006 12:18:11 -0500

contrary to somes wishes end nodes are going to have more knowledge of
path through a new services plane that will exist as client even on a
handheld thus assuming the ends will not have some knowledge to transfer
or report from that path I would suggest is not a good assumption.
/jim 

> From: John Leslie [mailto:[email-masked]] 
> Sent: Thursday, March 02, 2006 5:05 PM
> Cc: [email-masked]
> [email-masked] <[email-masked]> wrote:
> > To: <[email-masked]>, <[email-masked]>
> > 
> >>> ... while the Locator is a network layer address, the Endpoint
> >>> Identifier is a session layer concept, and what we're 
> really saying
> >>> is that we need some form of session management layer that lives
> >>> *above* the transport.
> >> 
> >> I agree. I'm not particular about the name; but there are
> >> many reasons to work on "session management":
> >> 
> >> - mobility;
> >> - security;
> >> - congestion;
> >> - pre-emption;
> >> - Quality-of-Service;
> >> - et cetera.
> > 
> > With regards to the "session", I think some notion of 
> 'path' is needed.
> > Path would essentially be the rough data path packets 
> traverse between
> > the address pairs one the two end-nodes. 
> 
>    Let me see if I understand... A "session" (your quotes) is defined
> by end-points, ports, and whatever; a 'path' is whatever limited
> knowledge the "session" management at each end-point may have about
> how packets get from one end to the other. Conceptually, there may be
> multiple paths in each direction for packet transfer.
> 
> > Each path will have some notion of congestion, admission / 
> premption /
> > policing and potentially security as well.
> 
>    I agree that congestion, pre-emption, etc. are per-path. Rules on
> admissible traffic and policing would be per-path, but may 
> not be fully
> known. Security practices would also be per-path, but I 
> wouldn't expect
> endpoints to have much knowledge of them.
> 
> > I think the notion of path is quite important if there are multiple
> > (potential) 'connections' beneath the session.  
> 
>    I'm not sure what you mean by 'connections'. I haven't 
> been thinking
> in terms of multiple 'connections' making up one session; rather I've
> been thinking of multiple 'paths' behaving as a single 'connection'.
> (Note, I don't mean to say that a single 'connection' implies a single
> stream of data.)
> 
> > surely will effect the overall session. 
> 
>    I would expect all of these to differ for different 
> 'paths'. Ideally,
> the "session" management will be able to discover all these.
> 
> > I think we're already finding issues when running apps with various
> > small devices over cellular & wifi radios, for example.  
> > 
>    I'm reasonably sure traditional TCP congestion-control 
> behaves badly
> under fairly common mobility situations.
> 
> > This begs the question, should TCP-bis congestion be re-worked?
> 
>    IMHO, yes.
> 
> --
> John Leslie <[email-masked]>
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 3 Mar 2006 12:24:40 -0500

SIP is just one incantation of a session but I think it far to limiting
to our thinking to say just SIP.  SIP is good use case for us I believe.
/jim 

> Sent: Thursday, March 02, 2006 7:19 PM
> To: Schumacher Laurent
> Schumacher Laurent <[email-masked]> wrote:
> > John Leslie wrote :
> > 
> >> I agree. I'm not particular about the name; but there are many
> >> reasons to work on "session management":
> >>
> >> - mobility;
> >> - security;
> >> - congestion;
> >> - pre-emption;
> >> - Quality-of-Service;
> >> - et cetera.
> >>
> > Isn't it what Session Initiation Protocol (SIP, RFC 3261) 
> is addressing?
> 
>    To tell truth, I don't know. I took RFC3261 at its word:
> " 
> " SIP is an agile, general-purpose tool for creating, modifying, and
> " terminating sessions that works independently of underlying 
> transport
> " protocols and without dependency on the type of session 
> that is being
> " established.
> 
> ... which is pretty open-ended. OTOH, it goes into so many details of
> multimedia that I'm left scratching my head whether it can deal with
> anything else.
> 
>    In any case, when I say "TCP-bis session" I'm thinking of ordinary
> stuff like web-surfing, instant messaging, and email, not multimedia.
> 
>    Perhaps someone else can enlighten us whether SIP sessions are
> the right animal to be discussing? (I'd be happy to start saying
> "SIP session" instead of "TCP-bis session"...)
> 
> --

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 07 Mar 2006 03:57:58 +0100

>various layers. I include a questioned layer, which I think Tony is
>alluding to, and the ISO and XNS Session models, which have some
>history. I suspect that we will have various comments on these
>architecturally, and when we get this part of the question sorted
>out, we will have a better notion of what further we might want to say.

As usage oriented, I will add a few layers:

Dioptres layers
all the dioptres in the physical layer. These are the computer 
systems, the different kind of techologies, the impact of external 
changes. For example crossing a boarder (rates, law, language, etc.)

>physical layer:
>link layer:
>Network layer:
>Intranet Layer:
>Internet Layer:
>Transport layer:
>Session Layer:
>Application Layer:

I consider the users system as part of the network architecture.
1. this makes three different main layers:
     - infrastructure - basic service to the data - interconnexion
     - superstructure - value added services to the enveloppe - 
interoperability
     - metastrucuture - extended services to the content - interintelligibility
2. this makes subnetwork layers to be considered.
     - intranets at infrastructural layer (you noted it)
     - externet at superstructural layer (external network look-alike 
using the network resources)
     - sets (spaces of exchanges, trust and services) at 
metastructural layer - what users perceive as relational/service network.
3. I will add the ENSM (extended network system model) upper layers:

Interapplications layer
Manage relations independently from the network technologies and the 
way their similar applications behave. Assist in preparing a uniform 
interintelligibility

Agent layer
Assitance to the user in interfacing the applications.

User
Users and communities. Their common understanding of the way to use 
the system is the system brainware. Digital cultures varies (most 
probably increasingly) among nations, languages, cultures, 
communities, ages, etc.

Communicating structures
Many factors modify the communications strategies and abilities of a 
structure. A communications architecture must have the necessary 
parameters to adapt.

Society
The way the society perceives, develops and rule its digital 
ecosystem has an obvious impact in its communications solutions. (ex. WSIS)

Maintenance, Operations and Brainware (consensual usage ways) are not 
layers as such but they must be embedded in the architecture.

Different elements must be considered as part of an architecture:
- security and trust
- multilingualism - independence from and equal support of every 
language, culture, etc
- user identification, privacy and empowerment (control of his global 
network zone)
- statistics and billing
- evolution and transition

jfc