Subject: RE: [arch-d] transport layer identifier evolutiion to support multihoming

From: "Bound, Jim" <[email-masked]>
Date: Fri, 1 Dec 2006 09:55:02 -0500

John,

> Jim, I am terrible sorry if you were offended by my choice of 
> language.  It was not intended as elitist or insulting in the least. 
> I think you are reading far too much into it.

As we talked offline I will accept that I overreacted and you did not
mean how I took it (taking my moral inventory in a sense which
elitistism permits in my view).  As I said offline and will share here I
a doing my best to live in this new politically correct world and as
best I can to keep my responses in form to a U.S. Mid-West News Caster
void of emotion and be teflon to my own biases when raised.  I much
liked the old days when we could kick and scream and I recall one mail a
long time ago where one said "YYY person you ignorant XXXX" from the old
U.S. Saturday Night Live skits.  But those days are gone and I accept
that and to be honest this today seems more productive for IETF
cyberspace conversations.  

> 
> I have worked (and am working) in more than one of 
> terminology with respect to this work.  And I was merely 
> recognizing that.  There was no value judgement in it 
> whatsoever.  As for preferring to call them endpoint 
> identifiers.  If you look at how the use of source and 
> destination port-ids arise in this class of protocols, i.e. 
> not only transport but also data link.  (They are basically 
> the same thing.)
> 
> Working from first principles (consider just two machines 
> trying to communicate), you find that the reason they first 
> appear is to distinguish multiple flows on the line.  Since 
> either end may initiate a connection, it is not feasible for 
> just one end to assign the connection-id.  If they did, there 
> would always be the chance of collisions.  Since both sides 
> already had a port-id that their local IPC was using to 
> distinguish the flow locally.  The convention has been to 
> concatenate them as the connection-id.
> 
> So the reason, I refer to the field as a connection-id is 
> that is its function in the protocol.  Each port-id can be 
> seen as a local-identifier of an endpoint.
> 
> Does that explain it?

Yes completely though I am not clear both ends need the same
connection-id.

My reasons for end-point-id was it also implies the packet has been
delivered and not being routed further and how does that play into our
model for analysis too?

Best,
/jim

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

---

From: John Day <[email-masked]>
Date: Fri, 1 Dec 2006 10:13:24 -0500

At 9:55 -0500 2006/12/01, Bound, Jim wrote:
>s

;-)  I know what you mean!  lol.  But that doesn't mean we can't give 
each other a bit of bad time once in awhile.  I expect it! ;-)  Just 
so you know, I am doing as much the same as you, but trying to keep 
it light.

>Yes completely though I am not clear both ends need the same

Well, once you have multiple sources.  If one end were choosing the 
conn-id, then the other end could end up with collisions from 
different sources and it would have to do more work to keep them 
disambiguated.  He could, but using two local-ids known to be 
unambiguous in their local context ensures that together they are 
unambiguous in both contexts.

(And probably the biggest reason, is it is the traditional way to 
solve the problem from long before it was used in TCP. ;-))

>delivered and not being routed further and how does that play into our

Yes, okay.  But strictly speaking, the protocol in which 
conn-id/endpoint-id occurred never knew it was routed.

Another important property of this class of protocols which I think 
needs to be preserved and isn't by SCTP is that all of their 
functionality is dedicated to a single instance, a single connection. 
There need not be any cross connection shared state.  Whether you do 
this in actual implementation is your choice, but you don't have to.

It turns out that this focus/isolation has some very nice properties 
when you start putting things together.

Later,  I have some real work that must get done!
John

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 3 Dec 2006 18:23:02 -0500

> ;-)  I know what you mean!  lol.  But that doesn't mean we 
> can't give each other a bit of bad time once in awhile.  I 
> expect it! ;-)  Just so you know, I am doing as much the same 
> as you, but trying to keep it light.

Agree we are human after all :--)

> Well, once you have multiple sources.  If one end were 
> choosing the conn-id, then the other end could end up with 
> collisions from different sources and it would have to do 
> more work to keep them disambiguated.  He could, but using 
> two local-ids known to be unambiguous in their local context 
> ensures that together they are unambiguous in both contexts.

Good point but I believe the two ends are mutually exclusive and should
not overlap in the name space that would support such as we discuss
here.

> 
> (And probably the biggest reason, is it is the traditional 
> way to solve the problem from long before it was used in TCP. ;-))

That is probably the key reason I would let go if the world will get
connection-id don't want to add the cost of re-education for sure.

> conn-id/endpoint-id occurred never knew it was routedFrom [email-masked] Sun Dec 03 18:25:18 2006
Content-class: urn:content-classes:message
Subject: RE: [arch-d] transport layer identifier evolution to support
	multihoming
Date: Sun, 3 Dec 2006 18:23:02 -0500
From: "Bound, Jim" <[email-masked]>
To: "John Day" <[email-masked]>, "John Leslie" <[email-masked]>
Cc: [email-masked]

> ;-)  I know what you mean!  lol.  But that doesn't mean we 
> can't give each other a bit of bad time once in awhile.  I 
> expect it! ;-)  Just so you know, I am doing as much the same 
> as you, but trying to keep it light.

Agree we are human after all :--)

> Well, once you have multiple sources.  If one end were 
> choosing the conn-id, then the other end could end up with 
> collisions from different sources and it would have to do 
> more work to keep them disambiguated.  He could, but using 
> two local-ids known to be unambiguous in their local context 
> ensures that together they are unambiguous in both contexts.

Good point but I believe the two ends are mutually exclusive and should
not overlap in the name space that would support such as we discuss
here.

> 
> (And probably the biggest reason, is it is the traditional 
> way to solve the problem from long before it was used in TCP. ;-))

That is probably the key reason I would let go if the world will get
connection-id don't want to add the cost of re-education for sure.

> conn-id/endpoint-id occurred never knew it was routedFrom [email-masked] Sun Dec 03 18:25:18 2006
Content-class: urn:content-classes:message
Subject: RE: [arch-d] transport layer identifier evolution to support
	multihoming
Date: Sun, 3 Dec 2006 18:23:02 -0500
From: "Bound, Jim" <[email-masked]>
To: "John Day" <[email-masked]>, "John Leslie" <[email-masked]>
Cc: [email-masked]

> ;-)  I know what you mean!  lol.  But that doesn't mean we 
> can't give each other a bit of bad time once in awhile.  I 
> expect it! ;-)  Just so you know, I am doing as much the same 
> as you, but trying to keep it light.

Agree we are human after all :--)

> Well, once you have multiple sources.  If one end were 
> choosing the conn-id, then the other end could end up with 
> collisions from different sources and it would have to do 
> more work to keep them disambiguated.  He could, but using 
> two local-ids known to be unambiguous in their local context 
> ensures that together they are unambiguous in both contexts.

Good point but I believe the two ends are mutually exclusive and should
not overlap in the name space that would support such as we discuss
here.

> 
> (And probably the biggest reason, is it is the traditional 
> way to solve the problem from long before it was used in TCP. ;-))

That is probably the key reason I would let go if the world will get
connection-id don't want to add the cost of re-education for sure.

> conn-id/endpoint-id occurred never knew it was routed.

True it could have been on the same machine under a guest OS via XEN or
VMWARE and this is influencing my name too (which I now take back) the
transport connection IDs are also important to the upper applications
(which I don't suggest we dive into) and the instances of
virtualization, clusters, and other forms distributed computing at the
services layers evolving will need to alter the physical space that
handle the connections and I am thinking can we avoid migrating
transport identifiers as doing this with the complete tcp (one example)
state today is quite complex.  A transport identifier would be far
easier to either change or migrate (hand waving here for now clearly)
when it is not associated with location coordinates for network path.
The win here for this discussion and hopeful outcome is far beyond just
the routing core the IAB reported and caused us to begin here (well it
was kind a going on before I know).

> 
> Another important property of this class of protocols which I 
> think needs to be preserved and isn't by SCTP is that all of 
> their functionality is dedicated to a single instance, a 
> single connection. 

Yes SCTP kept that property but an option could enhance where your going
and no chance with TCP.

> There need not be any cross connection shared state.  Whether 
> you do this in actual implementation is your choice, but you 
> don't have to.

Agree.

> 
> It turns out that this focus/isolation has some very nice 
> properties when you start putting things together.

Agree.

> Later,  I have some real work that must get done!

Can fully and completely understand I am trying hard to keep up here it
is important discussion.

/jim