Subject: [arch-d] Name this concept

From: John Leslie <[email-masked]>
Date: Wed, 1 Mar 2006 02:16:30 -0500

Fred Baker <[email-masked]> wrote:
> On Feb 27, 2006, at 10:47 PM, Bound, Jim wrote:
> 
>> Problem: Transport Layer needs to provide in the market failover to  
>> new IP address, but not tear down the IP session association. TCP/ 
>> UDP do not provide session layer failover to multiple IP  
>> addresses.  SCTP does permit this behavior.  How do we deprecate  
>> TCP/UDP so SCTP can become the dominant NGN for the Transport  
>> Layer, is there anything the IETF can do? (Ignoring DCCP for this  
>> example).
> 
> The architectural question is really, I think, to complete the  
> separation between the internet and transport layers, so that a  
> transport layer session is not tied to a single address pair.

   Exactly. It is good that SCTP does this, but SCTP is engineering,
not architecture.

> In TCP, we could simply copy the SCTP approach, which has the session
> tied to a single address pair at any given time, or we could have
> each TCP-speaker simply announce to the other the various addresses
> it might use, and once the announcement has been reliably received,
> have it assume that segments might arrive from any of the peer's
> announced addresses to any one of this system's addresses, but using
> the same port pair and other TCB state.

   This is architecture. "Reliably received", of course, is handwaving;
but that's OK in an architecture discussion.

   The critical issue is that there would be multiple paths, with each
endpoint (potentially) having multiple IP addresses.

> In that case, the peer is able to spread his traffic on all address
> pairs if it suits him, or change them at a whim, because instead of
> the TCP session having one address/port-pair tuple that identifies it,
> it has m*n identifiers that are mutual aliases, all equally valid at
> any given time.

   Note the use of "TCP session"...

   Fred certainly doesn't mean TCP-as-we-know-it-today; but it might
be better to say "TCP-bis"...

   Regardless, we need a way to talk about this "TCP-bis session".
I'm quite open to suggestions, but for now I'll use "TCP-bis session".

>> - Important to SHIM6, HIP, and Mobile IP. Are these priorities and  
>>   are they building shims around TCP/UDP.
> 
> Personally, I think each of these has its place operationally and yet  
> is also something of a kluge and overkill. That, to me, is the single  
> biggest reason that the marketplace hasn't necessarily adopted them  
> or is driving these solutions.

   I agree with Fred. But again, we need to talk architecture: those
are engineering...

> If TCP and SCTP can announce an alternate address like I described  
> above, now add the concept that they could withdraw an announced  
> address. Mobile handover just got fixed - at least the easy case in  
> which there is a multiple RTT overlap during which the moving  
> endpoint can send a message that announces the new address and  
> withdraws the old one.

   This is a nice architectural solution, free of most kludgery that
we see in typical "mobility" engineering.

   (Fred goes on to discuss engineering of announcing addresses. I
mostly agree with him, but I want to stick to architecture.)

> ... That would require some concept of a session identifier... See
> RFC 2103.

   No thanks on 2103 (16 pages). It really doesn't discuss "session".

   But "session identifier" is architecture: we should discuss it.

> Say "Locator/Endpoint Identifier split" (RFC 1992)...

   (27 pages.) Nice work, actually; but I think we can stay away from
routing for the time being.

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

> Note I didn't say "the ISO Session Layer" - please God, no - but
> something that lives in about that place and securely manages sessions.

   We need a name for this animal. I quite agree that "ISO Session"
won't do...

   "TCP-bis session" is ugly, but I think it gets the idea across.
Any other suggestions?

--
John Leslie <[email-masked]>

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

---

From: Tony Li <[email-masked]>
Date: Wed, 01 Mar 2006 00:56:38 -0800

>    "TCP-bis session" is ugly, but I think it gets the idea across.

The work on GSE/8+8 points out that if we have a host identifier and use
that as part of the pseudo-header, that that is sufficient to identify
the connection.  Such a host identifier obviates the real need for a
session layer and the possible ISO-ish trap.

That said, the more general "endpoint identifier" provides another level
of indirection over the host identifier, and yes would be a session
layer entity.  However, the architectural overhead for this indirection
is non-trivial and to me only seems to be advantageous over a host
identifier if we actually expect to migrate endpoints across hosts.  Do
we really have significant drivers for that in the architecture?  While
it has always been a pet interest of mine, I find the minimalistic side
of my nature rebelling.

That said, I actually do see a crying need for a real session layer.  We
seem to kludge this currently (e.g., X tunneled over SSH) and perhaps
for security reasons alone, we should bite the bullet and do it properly.

Thoughts?

Tony

---

From: Geoff Huston <[email-masked]>
Date: Wed, 01 Mar 2006 22:00:41 +1100

>for security reasons alone, we should bite the bullet and do it properly.

'host' always appears to me to be a somewhat indistinct and messy
kludge, given the somewhat indistinct and morphable definition of
what a 'host' is. I must admit that I had always associated the
term 'end-point' with an instance of a protocol stack. The reason
why is that at least at the application layer such an identifier is
used both in the context of establishing a conversation and
in maintaining a conversation. The association of such an identifier as
a session layer identity appears to me to be consistent with the
second of these roles, but its connotations in terms of being a
identification of a rendezvous point is a little harder to think
of in a session layer context. Either way the point that this is
non-trivial is well taken, but there is some merit to 'do it properly'
as far as I can see.

regards.

Geoff

---

From: <[email-masked]>
Date: Wed, 1 Mar 2006 15:28:08 +0200

John,

>> 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.  Each path will have some
notion of congestion, admission / premption / policing and potentially
security as well. I think the notion of path is quite important if there
are multiple (potential) 'connections' beneath the session.  

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: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 01 Mar 2006 10:26:36 -0500

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

---

From: Tim Shepard <[email-masked]>
Date: Wed, 01 Mar 2006 10:56:02 -0500

>    "TCP-bis session" is ugly, but I think it gets the idea across.

I like the idea of calling it an association.

Today (at least in our heads, if not in our systems) we can have shim6
associations, HIP associations, and IPsec associations.

So perhaps we need a simple small word to stick in front of
"association" to explicitly genericize the concept a bit for use in
architectural discussions.

I also think it may make sense (in our architectural thinking and
discussions) to avoid insisting on an ordering in the stack between
the transport layer stuff (e.g. TCP) and this [generic] association.
ISO had it above transport.  Mobile IP, HIP, shim6, IPsec all have an
end-to-end (or end-to-middlebox) association below transport that can
be shared by multiple transports (that go between the same two
endpoints).  The channel binding stuff being discussed in BTNS
illustrates (IMHO) that there's usefulness to be found both above and
below the transport layer (at least in being able to interface to the
association layer).

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Mar 2006 08:31:17 -0800

> architectural discussions.

Skip the adjective. Just call it what it is: "connection".

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Mar 2006 09:04:09 -0800

Geoff Huston wrote:
...
> in maintaining a conversation....

There's more than that - the association of other apps with that single
stack instance. Marco Zec's Clonable Stacks already implements this for
FreeBSD.

IMO, that's still a "host", since there are non-protocol issues involved
(application access, filesystem, etc.) that need to be partitioned 'per
stack' as well.

We need to relax the notion of "host" from mapping 1:1 to a computer,
but we have been for a while. In the early 1990s, Netstation and the
Desktop Area Network (DAN) extended that map to 1:N; In the late
1990s/early 2000s Clonable Stacks and supporting virtual OS's (Xen,
VMware, etc.) extended the map to M:1, and the supercomputer folk have
been working on ways to unify the two to support arbrary M:N maps for a
while (since the mid 1990s as well).

Joe

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Mar 2006 10:53:26 -0800

Hi -

> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 01, 2006 5:28 AM
> Subject: RE: [arch-d] Name this concept
...
...

I think this leads naturally to the conclusion that when
an session / association is created, the application could
specify the bounds for the end-to-end QoS, which would in
turn serve to constrain the underlying transport parameters,
including the decision whether to use connection-oriented or
connection-less transport (or even both).

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Mar 2006 10:47:33 -0800

Hi -

> From: "Tim Shepard" <[email-masked]>
> To: "John Leslie" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, March 01, 2006 7:56 AM
> Subject: Re: [arch-d] Name this concept 
...
...

As do I.  However, the term might lead to confusion with ACSE.
I'm not sure yet whether this would be a bug or a feature.

Randy

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Mar 2006 06:48:51 -0500

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.

---

From: Tony Li <[email-masked]>
Date: Thu, 02 Mar 2006 12:10:23 -0800

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

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 2 Mar 2006 16:02:36 -0500

> issues when running apps with various small devices over cellular & wifi

Another important one is a difference in path MTU.
 
> the question, should TCP-bis congestion be re-worked?

This has been looked at a little and discussed some in TSVWG and TCPM.

Currently, two internet-drafts that modify TCP to deal better with
different kinds of connectivity changes are being merged together:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12091
and
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=10165
The merged version is not yet available, and (sadly) there hasn't been
a strong WG response that this is even a valid issue that requires
work.

The two questions that remain, even if these changes to TCP are actually
adopted are:

  1) What are the standard signals from lower layers that TCP can use to
     trigger such actions?  I think getting these nailed down is an
     important part of the protocol architecture.

  2) Do we require a mandate that other protocols that rely on estimates
     of path state adopt similar mechanisms for responding to lower layer
     change indications?

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12376
is a starting point for the discussion.

-Wes

-- 
Wesley M. Eddy
Verizon Federal Network Systems

---

From: John Leslie <[email-masked]>
Date: Thu, 2 Mar 2006 17:04:57 -0500

[email-masked] <[email-masked]> wrote:
> To: <[email-masked]>, <[email-masked]>
> 
> 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.  
> 
> moblity solutions & extensions that the IETF is working on. 

   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.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 03 Mar 2006 00:05:10 +0100

> >many reasons to work on "session management":

Full agreement. I just add that in my "upper layers" usage 
architecture perspective it includes content oriented services as well.

>the address pairs one the two end-nodes.

There is a need to differentiate between the 
intended/requested/ordered path - something one can repeat, and the 
real path of the data. I would tend to say route/path ?

>  Each path will have some

Full agreement. Now can you clarify is the potentional connections 
are intrinsic or accidental to the session in your vision. I mean do 
you consider that ends may "weld" different connections with 
different kind of traffic (data, signals, types of content, etc.)? Do 
you consider that a session can accept different connections with 
different ends (like for a conference?). If yes, do you consider them 
as in a star or as in a meshed network?

>issues when running apps with various small devices over cellular & wifi

True. But this is also true (not only in technical terms) if you have 
multiple connection sessions using different technologies, legal 
domains, encryption, etc).

>the question, should TCP-bis congestion be re-worked?

Probably yes. But if you answered yes to some of the questions, it is 
not only a point for TCP but a point for a smart end. In that case 
what about OPES like systems which may assist the end management: are 
they part of the session or to be differently perceived and named (I 
call them exchanges).

Question: do you accept to consider in your vision multiple 
asynchornous session as part of a relation obeying to common rules/parameters?

---

From: Tony Li <[email-masked]>
Date: Thu, 02 Mar 2006 15:44:39 -0800

> under fairly common mobility situations.

I think that it's been pretty widely documented that current TCP
congestion-control pretty much goes in the can with as little as 1%
packet loss.  Folks have demonstrated that employing FEC, for example,
can dramatically improve these types of situations.

However, this is again a subject for transport folks to work on, and
really isn't rightfully an architectural subject, IMHO.

Tony

---

From: John Leslie <[email-masked]>
Date: Thu, 2 Mar 2006 19:05:31 -0500

> turn serve to constrain the underlying transport parameters,

   I do think this would be helpful...

> connection-less transport (or even both).

   I can wrap my mind around the idea that a "session" could use a
connection-less transport; but I find it confusing: it immediately
brings up the question, "What does 'connectionless session' mean?

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Mar 2006 17:41:26 -0800

Hi -

> From: "John Leslie" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Sent: Thursday, March 02, 2006 4:05 PM
...
...

I'm not sure calling a session "connectionless" is helpful.  An example
of something which could sensibly be modeled as a session employing
a connectionless transport would be SNMPv3 auth-priv (including initial
clock synchronization) over UDP. There's no connection in any traditional
sense, and reordering of packets (within a temporal window) is tolerated,
but there is definitely an "association" or "session" in terms of authentication
keys, privacy keys, and clock sync (not to be confused in any way with
what goes on in protocols like NTP)for each pair of engines communicating
on behalf of some user.  This has resurfaced in the discussions of the
isms working group.

Randy

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 03 Mar 2006 13:03:03 +0100

>brings up the question, "What does 'connectionless session' mean?

Signals? Semaphores?
jfc

---

From: John Leslie <[email-masked]>
Date: Fri, 3 Mar 2006 12:08:00 -0500

> https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12091

" The basic idea is to trigger a speculative retransmission attempt when
" a TCP implementation receives an indication that connectivity to a
" previously unreachable peer node may have returned.

> https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=10165

" This document describes a TCP option that allows a connection endpoint
" to inform a peer when it changes location. This document also outlines
" the proper congestion control behavior that should take place in the
" face of such network layer mobility.

   For our purposes, I think the second is more interesting...

" ACKs received for packets sent on the old path do not indicate the
" congestion state of the new path, and should not be used in the
" computation of TCP's congestion window.

   Agreed.

" Slow-start based probing from the initial window should take place in
" the new path, with the slow-start threshold (SS_THRESH) reset to its
" initial value.

   This is not attractive -- unless we can arrange for the slow-start
to overlap transmission across the old path for long enough to reach
stability, or at least equivalent bandwidth to the old path.

" 3.  Congestion Control Issues with Subnet Change
"...
" During the transitional period, when MN moves from Old to New Subnet,
" AR-1 might not be able to deliver packets it receives which are
" addressed for MN.  This could result in a large burst of packet loss.

   ... quite unrelated to congestion, of course.

" To address this, there are several suggested means of doing "fast" or
" "seamless" handovers, which involve adding machinery in the ARs to
" buffer and redirect packets originally sent to the Old Subnet, to the
" New Subnet...
" In the alternative scenario, all packets destined to <Subnet-1, MN>
" are forwarded to <Subnet-2, MN> by AR-1 by some means

   This, of course, depends upon a middle-box which knows that one end
is mobile. I think we should discuss architecture, not engineering, and
that the discussion is simpler without middle-boxes.

   I also think it's conceptually simpler to consider the computer(s)
to receive packets on multiple IP addresses. Among other things, this
keeps path characteristics differentiated and more obvious.

   YMMV...

>    important part of the protocol architecture.

   Obviously, there's packet loss. Explicit congestion notification would
certainly be interesting. Possibly transit time might give some hints.

   But perhaps you mean explicit messages generated at one layer and
passed to another. I'd prefer not to go there, since
1) it's engineering, not architecture;
2) they're so easily forged;
3) automated interpretation is dangerous;
4) if generated at all, they're likely to get dropped along the way.

   Some equivalent of cell-tower handoffs may be worth discussing; but
I'm worried it might prove too expensive to implement. As a general rule,
we'd do well to limit discussion of signals-from-lower-layers to cases
with major and obvious benefits.

>    of path state adopt similar mechanisms for responding to lower layer

   I doubt we could enforce such a mandate. But if we do things right,
our mechanisms will prove attractive.

> is a starting point for the discussion.

" This document summarizes current proposals, describes the architectural
" issues and provides examples of appropriate and inappropriate uses of
" link layer indications.

   50 pages. (I haven't read every word.)

" 1.4.1.  Internet Layer
" 
" The Internet layer is the primary consumer of link indications, as
" one of its functions is to shield applications from the specifics of
" link behavior.  This is accomplished by validating and filtering link
" indications and selecting outgoing and incoming interfaces based on
" routing metrics.

   This deals mainly with link-up and link-down from a routing perspective.

" 1.4.2.  Transport Layer
" 
" The Transport layer processes Internet layer and link indications
" differently for the purposes of transport parameter estimation and
" connection management.

   A bunch of good stuff here, which I won't repeat.

" As described in Appendix A.3, the algorithms for improving transport
" parameter estimates using link layer indications are still under
" development.

   Good reading there, too, which I won't repeat.

" 1.4.3.  Application Layer
" 
" The Transport layer provides indications to the Application layer by
" propagating Internet layer indications (such as IP address
" configuration and changes), as well as providing its own indications,
" such as connection teardown.

   Not sure how applicable this section is...

" 2.  Architectural Considerations

   Eleven good points here (which I won't repeat).

====

---

From: John Leslie <[email-masked]>
Date: Fri, 3 Mar 2006 12:15:07 -0500

Tony Li <[email-masked]> wrote:
> To: John Leslie <[email-masked]>
> 

   Agreed.

> really isn't rightfully an architectural subject, IMHO.

   It's certainly an architectural subject _whether_ this beongs at
the transport level.

   And, IMHO, it's an architectural subject whether transport is getting
enough information to effectively deal with the issue; or whether better
information would be available at some other layer.

   (In short, I don't agree that such a subject should be off-limits
for architectural discussions.)

   Clearly, Forward Error Correction is an appropriate tool at some level.
We don't want to get into engineering details of how it's done; but a
"TCP-bis session" might well want to recommend its use, and might have
better information on suggested parameters.

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 3 Mar 2006 12:45:29 -0500

> passed to another. I'd prefer not to go there, since

There are two distinct, but related issues:

a) local message passing between stack layers on a single host
b) signaling relevent properties (address changes, etc) to remote hosts

> 1) it's engineering, not architecture;

The (lack of) architecture in this regard forces it to be engineered.
Engineering solutions in multiple ways for each combination of transport
and/or particular link layer

> 2) they're so easily forged;

And they're easily detected.

> 3) automated interpretation is dangerous;

Especially if there's no architectural guidance ...

> 4) if generated at all, they're likely to get dropped along the way.

Why would these be more likely than any other packet to be dropped?

-Wes

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 3 Mar 2006 13:42:22 -0500

Hello;

> information would be available at some other layer.

This is what Fecframe is supposed to do

https://www1.ietf.org/mailman/listinfo/fecframe

Regards
Marshall

---

From: <[email-masked]>
Date: Sun, 5 Mar 2006 14:57:22 +0200

Randy,  

>I think this leads naturally to the conclusion that when an 
>session / association is created, the application could 
>specify the bounds for the end-to-end QoS, which would in turn 
>serve to constrain the underlying transport parameters, 

Maybe, but what about real-time applications that can renegotiate 
codecs?  I've been thinking of a session-shim layer that would be
able to propigate up some info about the current association
characteristics, so if the upperlayer needed to react to changes
in the underlying connectivity, that would be available.

John

---

From: <[email-masked]>
Date: Mon, 6 Mar 2006 13:49:14 +0200

Hi Wes,

>Currently, two internet-drafts that modify TCP to deal better 
>with different kinds of connectivity changes are being merged together:
>The merged version is not yet available, and (sadly) there 
>hasn't been a strong WG response that this is even a valid 
>issue that requires work.
>
>The two questions that remain, even if these changes to TCP 
>are actually adopted are:
>

These are really good points, actually this could form good input to
some
things like SHIM6 - I think the triggers are a important issue - I
wonder
if this would be tied into the IP over Foo documents, for each potential
Foo layer.  Additionally, there is a lot of work going on in groups like

DNA (Detecting Network Attachment) where the above drafts could have
some
discussion.

John

---

From: <[email-masked]>
Date: Mon, 6 Mar 2006 13:51:54 +0200

John,

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

Well, maybe this is some part of the terminology we should nail down,
or we will get completely lost.  I was thinking that a session would
be name for multiple paths, especially if separate TCP connections
(for example) were used.

>> very different RTT, latency, packet loss, etc. for these paths, and 
>> that 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.

Agreed.

John

---

From: <[email-masked]>
Date: Mon, 6 Mar 2006 13:54:41 +0200

JFC,

>Full agreement. Now can you clarify is the potentional 
>connections are intrinsic or accidental to the session in your 
>vision. I mean do you consider that ends may "weld" different 
>connections with different kind of traffic (data, signals, 
>types of content, etc.)? Do you consider that a session can 
>accept different connections with different ends (like for a 
>conference?). If yes, do you consider them as in a star or as 
>in a meshed network?

I'm considering that the final endpoints of the communication would
be the same - host-to-host sessions.  I think multiparty communication
is a different issue.

>>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.
>
>True. But this is also true (not only in technical terms) if 
>you have multiple connection sessions using different 
>technologies, legal domains, encryption, etc).

Agreed.

>Probably yes. But if you answered yes to some of the 
>questions, it is not only a point for TCP but a point for a 
>smart end. In that case what about OPES like systems which may 
>assist the end management: are they part of the session or to 
>be differently perceived and named (I call them exchanges).
>

If I understand you correctly, this is above the session layer,
and more at the application layer.

John

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Mar 2006 13:13:21 -0800

> Do we want this flexibility in the transport protocol?  Or should  

That's up for discussion. I think we want the transport to be able to  
handle changes of address at the network layer, and as I said there  
are cases in which network connectivity can be completely lost using  
one address and and later restored using another. If the transport  
session cannot be re-targeted to the new address with appropriate  
security, we have a problem. That says we somehow want to have the  
retargeting happen.

Next question is "same layer or one in between". I would tend to  
think of the one in between as being an API demultiplexing layer,  
which sounds to me like a sublayer of the transport. That's not a  
firm position, but my current hunch, and squares with the current  
SCTP implementation.

>> architecture.

---

From: Tony Li <[email-masked]>
Date: Mon, 06 Mar 2006 16:08:24 -0800

> Next question is "same layer or one in between". I would tend to think
> of the one in between as being an API demultiplexing layer, which sounds
> to me like a sublayer of the transport. That's not a firm position, but
> my current hunch, and squares with the current SCTP implementation.

Interesting.  My preferences would be to have this be wholly underneath
transport, as I would hate to have to recreate this functionality
separately for each transport protocol.  UDP based traffic should be
able to take advantage of these mechanisms too.

Tony

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 06 Mar 2006 23:15:43 +0100

>be the same - host-to-host sessions.  I think multiparty communication

Communication is a generic term. We are talking of a session and connection.
I understand you say it is a different issue. However broadcast, 
multicats, anycasts are multiparty?

>and more at the application layer.

This is a good question. It is above the session layer since it 
considers several sessions. But to which extent because:
- this can be several sessions in succession. There is no "time layer" yet.
- this can be application - same application for all the sessions.
- this can be interapplication - different applications throughout 
the sessions.

FYI, my model (ENS, 1985) includes layer 8 interapplications, 9 user 
agents, 10 users, 11 communicating structures, 12 society and 0 dioptres.

jfc

---

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

FYI, my model (ENS, 1985) [email-masked] a.com>
Cc: [email-masked], [email-masked]

jfc

cludes layer 8 interapplications, 9 user 
agents, 10 users, 11 communicating structures, 12 society and 0 dioptres.

jfc