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

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

John, good point but I think the IP-Session-ID for say multiple
transport connections is more of a conrol plane transport where as for
example the SCTP associations underneath are specific instances of
transport connection that would weigh in on the overall nodes knowledge
of the transport connection.  Also each connection for each media layer
would need to provide metrics for that network path as you state
regarding hints and intelligence and security.

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, March 01, 2006 8:28 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Bound, Jim
> Subject: RE: [arch-d] Name this concept
> 
> John,
> 
> A quick additional point:
> 
> >> ... 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.  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
> 

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

---

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

Jim,

That is one solution for it, and I think something that would work now.
I was
bumping up to a higher-view.

John 

>From: ext Bound, Jim [mailto:[email-masked]] 
>Sent: 01 March, 2006 19:16
>To: Loughney John (Nokia-NRC/Helsinki); [email-masked]; [email-masked]
>Cc: [email-masked]
>John, good point but I think the IP-Session-ID for say 
>multiple transport connections is more of a conrol plane 
>transport where as for example the SCTP associations 
>underneath are specific instances of transport connection that 
>would weigh in on the overall nodes knowledge of the transport 
>connection.  Also each connection for each media layer would 
>need to provide metrics for that network path as you state 
>> >   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.
>> 
>> security as well. I think the notion of path is quite important if 
>> there are multiple (potential) 'connections' beneath the session.
>> 
>> 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.
>>