RE: The internet architecture

[John C Klensin]

--On Sunday, 28 December, 2008 16:22 -0500 John Day
 wrote:

> Why should an application ever see an IP address?
> 
> Applications manipulating IP addresses is like a Java program
> manipulating absolute memory pointers. A recipe for problems,
> but then you already know that.

John,

Let me try to explain, in a slightly different way, what I
believe some others have tried to say.

Suppose we all agree with the above as a principle and even
accept your analogy (agreement isn't nearly that general, but
skip that for the moment).  Now consider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name.   One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as bad as knowing
about the addresses -- one DNS name per interface is more or
less the same as one DNS name per address.

Now the application has to pick which interface to use in, e.g.,
opening a connection to another system.  Doing that optimally,
or even effectively, requires that it know routing information.
But requiring the application to obtain and process routing
information is worse than whatever you think about its using IP
addresses -- the latter may be just a convenient handle ("blob")
to identify what we have historically called an interface, but
having the application process and interpret routing information
is completely novel as far as the applications layer is
concerned (as well as being a layer violation, etc., etc.) and
requires skills and knowledge that application writers rarely
have and still more rarely should need to use.


At least to me, that is the key architectural problem here, not
whatever nasty analogies one can draw about IP addresses.

john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Rémi Després]

John,

To pick a local interface for an outgoing connection isn't the
transport layer, e.g. SCTP, well placed to do the job (or some
intermediate layer function like Shim6)?
Thus, ordinary applications wouldn't need to be concerned.

RD

Actually SCTP is  it to some extent.

John C Klensin  -  le (m/j/a) 12/29/08 1:56 PM:

  
--On Sunday, 28 December, 2008 16:22 -0500 John Day
 wrote:

  
  
Why should an application ever see an IP address?

Applications manipulating IP addresses is like a Java program
manipulating absolute memory pointers. A recipe for problems,
but then you already know that.

  
  
John,

Let me try to explain, in a slightly different way, what I
believe some others have tried to say.

Suppose we all agree with the above as a principle and even
accept your analogy (agreement isn't nearly that general, but
skip that for the moment).  Now consider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name.   One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as bad as knowing
about the addresses -- one DNS name per interface is more or
less the same as one DNS name per address.

Now the application has to pick which interface to use in, e.g.,
opening a connection to another system. 

See above

   Doing that optimally,
or even effectively, requires that it know routing information.
But requiring the application to obtain and process routing
information is worse than whatever you think about its using IP
addresses -- the latter may be just a convenient handle ("blob")
to identify what we have historically called an interface, but
having the application process and interpret routing information
is completely novel as far as the applications layer is
concerned (as well as being a layer violation, etc., etc.) and
requires skills and knowledge that application writers rarely
have and still more rarely should need to use.


At least to me, that is the key architectural problem here, not
whatever nasty analogies one can draw about IP addresses.

john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

  




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[John Day]

No it isn't Transport's job.  Transport has one 
and only one purpose: end-to-end reliability and 
flow control.


"Managing" the resources of the network is the network layer's job.

Although, these distinctions of Network and 
Transport Layer are . . . shall we say, quaint.


Multihoming is fundamentally a routing problem. 
SCTP tries to claim to solve it by changing the 
definition, an old trick. Sort of like medieval 
medicine's response to a disease it can't cure: 
give you a disease I can cure and hope it works. 
Multihoming has nothing to do with what has 
traditionally been called the "Transport Layer."


It is a problem of routing not be able to 
recognize that two points of attachment go to the 
same place.  Portraying it as anything else is 
just deluding yourself.


At 14:22 +0100 2008/12/29, Rémi Després wrote:

John,

To pick a local interface for an outgoing 
connection isn't the transport layer, e.g. SCTP, 
well placed to do the job (or some intermediate 
layer function like Shim6)?

Thus, ordinary applications wouldn't need to be concerned.

RD

Actually SCTP is it to some extent.

John C Klensin - le (m/j/a) 12/29/08 1:56 PM:



--On Sunday, 28 December, 2008 16:22 -0500 John Day
 wrote:




Why should an application ever see an IP address?

Applications manipulating IP addresses is like a Java program
manipulating absolute memory pointers. A recipe for problems,
but then you already know that.




John,

Let me try to explain, in a slightly different way, what I
believe some others have tried to say.

Suppose we all agree with the above as a principle and even
accept your analogy (agreement isn't nearly that general, but
skip that for the moment).  Now consider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name.   One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as bad as knowing
about the addresses -- one DNS name per interface is more or
less the same as one DNS name per address.

Now the application has to pick which interface to use in, e.g.,
opening a connection to another system.


See above


 Doing that optimally,
or even effectively, requires that it know routing information.
But requiring the application to obtain and process routing
information is worse than whatever you think about its using IP
addresses -- the latter may be just a convenient handle ("blob")
to identify what we have historically called an interface, but
having the application process and interpret routing information
is completely novel as far as the applications layer is
concerned (as well as being a layer violation, etc., etc.) and
requires skills and knowledge that application writers rarely
have and still more rarely should need to use.


At least to me, that is the key architectural problem here, not
whatever nasty analogies one can draw about IP addresses.

john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: The internet architecture

[John Day]

Let me get this straight.  You are saying that there are other 
reasons why an application should never see an IP address? And you 
feel that your reason is more important than simply getting level of 
abstractions wrong. So you agree?


Yes, of course.  There are lots of ugly things that can happen.  You 
don't have to go very far to run into why.  The question is why have 
we insisted on not doing it right for so long?


Take care,
John


At 7:56 -0500 2008/12/29, John C Klensin wrote:

--On Sunday, 28 December, 2008 16:22 -0500 John Day
 wrote:


 Why should an application ever see an IP address?

 Applications manipulating IP addresses is like a Java program
 manipulating absolute memory pointers. A recipe for problems,
 but then you already know that.


John,

Let me try to explain, in a slightly different way, what I
believe some others have tried to say.

Suppose we all agree with the above as a principle and even
accept your analogy (agreement isn't nearly that general, but
skip that for the moment).  Now consider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name.   One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as bad as knowing
about the addresses -- one DNS name per interface is more or
less the same as one DNS name per address.

Now the application has to pick which interface to use in, e.g.,
opening a connection to another system.  Doing that optimally,
or even effectively, requires that it know routing information.
But requiring the application to obtain and process routing
information is worse than whatever you think about its using IP
addresses -- the latter may be just a convenient handle ("blob")
to identify what we have historically called an interface, but
having the application process and interpret routing information
is completely novel as far as the applications layer is
concerned (as well as being a layer violation, etc., etc.) and
requires skills and knowledge that application writers rarely
have and still more rarely should need to use.


At least to me, that is the key architectural problem here, not
whatever nasty analogies one can draw about IP addresses.

john


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[macbroadcast]

dear john day

would you please reply just to the list , sorry it was not my  
intention to make such a fuzz when i involved brians opinion about  
u.i.a.


Thanks for the other opinions aswell.

regards

and happy new year


Marc







Am 29.12.2008 um 16:32 schrieb John Day:

Let me get this straight.  You are saying that there are other  
reasons why an application should never see an IP address? And you  
feel that your reason is more important than simply getting level of  
abstractions wrong. So you agree?


Yes, of course.  There are lots of ugly things that can happen.  You  
don't have to go very far to run into why.  The question is why have  
we insisted on not doing it right for so long?


Take care,
John


At 7:56 -0500 2008/12/29, John C Klensin wrote:

--On Sunday, 28 December, 2008 16:22 -0500 John Day
 wrote:


Why should an application ever see an IP address?

Applications manipulating IP addresses is like a Java program
manipulating absolute memory pointers. A recipe for problems,
but then you already know that.


John,

Let me try to explain, in a slightly different way, what I
believe some others have tried to say.

Suppose we all agree with the above as a principle and even
accept your analogy (agreement isn't nearly that general, but
skip that for the moment).  Now consider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name.   One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as bad as knowing
about the addresses -- one DNS name per interface is more or
less the same as one DNS name per address.

Now the application has to pick which interface to use in, e.g.,
opening a connection to another system.  Doing that optimally,
or even effectively, requires that it know routing information.
But requiring the application to obtain and process routing
information is worse than whatever you think about its using IP
addresses -- the latter may be just a convenient handle ("blob")
to identify what we have historically called an interface, but
having the application process and interpret routing information
is completely novel as far as the applications layer is
concerned (as well as being a layer violation, etc., etc.) and
requires skills and knowledge that application writers rarely
have and still more rarely should need to use.


At least to me, that is the key architectural problem here, not
whatever nasty analogies one can draw about IP addresses.

   john




--
Les Enfants Terribles - WWW.LET.DE
Marc Manthey 50672 Köln - Germany
Hildeboldplatz 1a
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
mail: m...@let.de
jabber :m...@kgraff.net
IRC: #opencu  freenode.net
twitter: http://twitter.com/macbroadcast
web: http://www.let.de

Opinions expressed may not even be mine by the time you read them, and  
certainly don't reflect those of any other entity (legal or otherwise).


Please note that according to the German law on data retention,  
information on every electronic information exchange with me is  
retained for a period of six months.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Rémi Després]

Title: Re: The internet architecture




John Day  -  le (m/j/a) 12/29/08 4:24 PM:

  
  
  No it isn't Transport's job.  Transport has one and only one
purpose: end-to-end reliability and flow control.
  
  
  "Managing" the resources of the network is the network
layer's job.

Reliably... and also efficiently.
To transmit as fast as possible, including with load sharing among
several parallel paths, the flow control function (i.e. the transport
layer, right?) has, in my understanding, to know how many address
couples
it uses.

Whether the transport layer can delegate some of its flow control
function to an intermediate layer is IMO a terminology question.


  
  
  Although, these distinctions of Network and Transport Layer are
.
. . shall we say, quaint.

Yes, indeed.

  
  
  Multihoming is fundamentally a routing problem.  SCTP tries
to claim to solve it by changing the definition, an old trick. 

I am not sure what the two definitions are.
Being more specific would be helpful.

  ... Multihoming has
nothing to do with what has traditionally been called the
"Transport Layer."
  
  
  It is a problem of routing not be able to recognize that two
points of attachment go to the same place. ...

In my understanding, knowing that two locators are those of  a common
destination is  the normal result from getting these locators by
translation of an identifier, e.g. a domain name.

RD

  
  
  At 14:22 +0100 2008/12/29, Rémi Després wrote:
  John,

To pick a local interface for an outgoing connection isn't the
transport layer, e.g. SCTP, well placed to do the job (or some
intermediate layer function like Shim6)?
Thus, ordinary applications wouldn't need to be concerned.

RD

  





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART Last Call review of draft-korhonen-mip4-service-06

[Spencer Dawkins]

Hi, Jouni,

Thanks for your quick response - I'm OK with most of your proposed changes.

I should emphasize that my comments here are Last Call comments that you 
(and the document shepherd, and the AD) can decide to ignore - I'm just 
telling you what I'm seeing when I read the text.


Just to finish up:


 Some of the potential use-cases were listed earlier in this section.
 The general aim is better manageability of services and service
 provisioning from both operators and service providers point of view.
 However, it should be understood that there are potential deployment
 possibilities where selecting a certain service may restrict
 simultaneous access to other services from an user point of view.
 For example, services may be located in different administrative
 domains or external customer networks that practice excessive
 filtering of inbound and outbound traffic.

Spencer: I wasn't clear on who this understanding is directed to - it 
almost reads like you're warning users that bad things might happen if 
you use a specific service, but surely the user specifies the service 
because an operator requires this?


We had this discussion earlier on RFC5149.. and concerns were raised
whether the Service Selection is a potential tool for enabling walled
gardens etc. Thus this note here was added to emphasize that point.


I understand your point from your explanation, but can't get that 
understanding from the draft text. If you said


s/from a user point of view/from a user point of view (for example, a 
"walled garden")/


that would be as clear as your explanation.


3.  Service Selection Extension

 At most one Service Selection extension MAY be included in any Mobile
 IPv4 Registration Request message.  It SHOULD be included at least in

Spencer: seems to be missing a qualifier: "When a non-default service is 
selected, the Service Selection extension SHOULD be included ..."?


Spencer: If this is qualified, could the SHOULD be a MUST?


Hmm.. right. New text would be:

  At most one Service Selection extension MAY be included in any Mobile
  IPv4 Registration Request message.  When a non-default service is 
selected,

  the Service Selection extension SHOULD be included at least in
  the Registration Request message that is sent for the initial binding
  registration when the mobile node and the home agent do not have an
  existing binding.  The Service Selection extension MUST be placed in
  the Registration Request message as follows:



Spencer: If it remains as SHOULD, what happens if the Service Selection 
extension is not included in the initial binding registration, but is 
included in subsequent binding registrations?


The first RRQ would be treated as the selection of the "default
service". The subsequent RRQs with the service selection would cause
reauthorization & evaluation of the requested service. If the newly
requested service conflicts with the "default service" from the HA
point of view, then an appropriate error is returned and the binding
is dropped.


I'm still confused by


When a non-default service is selected,
  the Service Selection extension SHOULD be included at least in
  the Registration Request message that is sent for the initial binding
  registration when the mobile node and the home agent do not have an
  existing binding.


My understanding from your explanation is that, by definition, if you don't 
include the Service Selection extension, you aren't selecting a non-default 
service until you DO send an RRQ that includes the Service Selection 
extension - right? If I'm tracking you, you're talking about two cases at 
the same time - what happens if you DO include the extension in the first 
RRQ, and what happens if you DON'T include the extension in the first RRQ, 
then switch to a non-default service by including the Service Selection 
extension in a subsequent RRQ - that would be why I was confused.


I think your explanation is way clearer than the draft text - perhaps you 
could insert it into the draft text?


Thanks, and Happy New Year,

Spencer 



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: where to send RFC 5378 license forms

[Simon Josefsson]

"Donald Eastlake"  writes:

> On Fri, Dec 19, 2008 at 5:30 AM, Simon Josefsson  wrote:
> ...
>> If you are updating a pre-RFC 5378 document that contains trademarked
>> words, it isn't sufficient for the old contributor to have signed the
>> IETF Trust form if the document contains trademarks.  You need to
>> contact him anyway, to get permission to reproduce the trademark.
>>
>> /Simon
>
> You should consult an attorney but, as far as I know, at least in the
> US, there is no magic permission needed to "reproduce" a trademark.
> Usually trademarks are to indicate the source of a product or service
> and as long as you don't mislead people about that, you are fine.

Then what use does section 3.4 of RFC 5378 serve?

3.4.  Rights to Use Trademarks

   Contributors may wish to seek trademark or service mark protection on
   any terms that are coined or used in their Contributions.  The IETF
   makes no judgment about the validity of any such trademark rights.
   However, the IETF requires each Contributor, under the licenses
   described in Section 5.3 below, to grant the IETF Trust a perpetual
   license to use any such trademarks or service marks solely in
   exercising rights to reproduce, publish, discuss, and modify the IETF
   Contribution.  This license does not authorize the IETF or others to
   use any trademark or service mark in connection with any product or
   service offering.

It was co-authored by the IETF attorney, so I suspect it is intended to
serve some purpose.

If it serves a purpose, contributors needs to get the necessary right
and be able to transfer it to the IETF Trust in order to submit a
contribution.  As far as I understand, that would involve talking with
the old contributor if trademarks are involved.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Noel Chiappa]

> From: John Day 

> Multihoming is fundamentally a routing problem.

I have been thinking this for some time too, and it's especially true/clear
when the multi-homing in question is site multi-homing, and not
host-multihoming (which is much rarer, is my impression). You clearly have
two alternative paths to the destination, and have to pick.

Which raises the question of 'why not have the routing do it', and that's a
very valid question. In a routing architecture which had better - read
non-manually configured - _scopes_ for routing information, and more
automatic aggregation (or hiding, to use the more general concept), I think I
would agree that probably it should be hidden in the routing. (The "probably"
is because I'd have to see the actual details.)

However, we have to 'go to war with the army we have', and the current routing
architecture (which includes the _functional interface_ with the _rest_ of the
architecture, not just how it's arranged internally - and the former is
basically impossible to change) makes it impossible to do that.

> It is a problem of routing not be able to recognize that two points of
> attachment go to the same place. Portraying it as anything else is just
> deluding yourself.

I would agree with this, except I defer to the 'get down off an elephant'
principle. If both points of attachment are bound to a single transport level
entity, then it ought to be relatively easy, and not involve the routing at
all, to detect that both points of attachment lead to the same entity.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[John Leslie]

John Day  wrote:
> At 14:22 +0100 2008/12/29, R?mi Despr?s wrote:
>>
>> To pick a local interface for an outgoing connection[,]
>> isn't the transport layer, e.g. SCTP, well placed to do the job
>> (or some intermediate layer function like Shim6)?
> 
> No it isn't Transport's job.  Transport has one and only one purpose:
> end-to-end reliability and flow control.

   I must disagree with John Day.

   I accept "reliability and flow control" as the transport layer's
primary function, but denying it access to multiple interfaces cripples
its ability to perform those functions in a mobility environment.

   And, IMHO, from an architectural viewpoint, multi-homing and mobility
are the same problem.

> "Managing" the resources of the network is the network layer's job.

   That's only partly true, and completely irrelevant.

> Although, these distinctions of Network and Transport Layer are . . .
> shall we say, quaint.

   True, we can't seem to agree to a distinction and stick with it,
but "quaint" is hardly the right word -- it's more like "deja-vu all
over again."

> Multihoming is fundamentally a routing problem. 

   Absolutely not.

   Routing is a function of discovering connectivity and propagating
information about routes to routers that may want to use them.

   Multihoming is a funtion of maintaining alternate paths in order
to avoid interruptions of connectivity when a primary path hiccups or
becomes congested. (Just like mobility...)

   Multihoming _should_not_ wait for connectivity to fail altogether;
least of all should it wait for connectivity failure to propagate
through an internet.

   We have pretty good routing algorithms for _stable_ networks. We
have to kludge those algorithms to work _at_all_ in unstable networks.
Mobility by its nature _cannot_ be stable. (Multi-homing is most
often done as protection against occasional instability.)

> SCTP tries to claim to solve it by changing the definition, an old
> trick.

   Unfair! SCTP was designed for a specific function: it's quite honest
about the design choices. Don't blame its design for other things folks
are trying to use it for.

> Multihoming has nothing to do with what has traditionally been called
> the "Transport Layer."

   If so, perhaps it's time to refine those "definitions" of "Transport
Layer."

> It is a problem of routing not be able to recognize that two points
> of attachment go to the same place.

   Hardly!

   Routing finds paths between "nodes" using "links". These "nodes"
_are_ points of attachment, not computers (whatever those may be).
Routing _must_ deal in topology, not physical proximity.

> Portraying it as anything else is just deluding yourself.

   Again, hardly!

   We have been punting entirely too much to "routing" for decades.
There are other perfectly valid ways to divide the problem. And IMHO,
any way that makes the realm of "routing" reside in a "stable" space
is a _better_ paradigm.

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[John Day]

At 17:04 +0100 2008/12/29, Rémi Després wrote:

John Day - le (m/j/a) 12/29/08 4:24 PM:


Re: The internet architecture
No it isn't Transport's job. Transport has one 
and only one purpose: end-to-end reliability 
and flow control.


"Managing" the resources of the network is the network layer's job.


Reliably... and also efficiently.


Definitely.

To transmit as fast as possible, including with 
load sharing among several parallel paths, the 
flow control function (i.e. the transport layer, 
right?) has, in my understanding, to know how 
many address couples it uses.


Strictly speaking, no, I would disagree that 
these are transport functions. Transport has no 
need to know any address couples.  That is why it 
has a connection id, i.e. concatenated port-ids. 
But then as I said, there really is no distinct 
transport or network layer.


This is where things get involved. because really 
the boundary between network and transport is a 
false boundary.  The last remnant of 
"beads-on-a-string" thinking.  One sign of this 
is the need for a protocol-id field in IP.  If we 
hadn't gotten into a battle with the PTTs over 
whether or not we needed a Transport Layer at 
all, I think we would have seen this a lot 
sooner.  But the battle caused lines to be drawn 
and forces to dig in.  ;-)




Whether the transport layer can delegate some of 
its flow control function to an intermediate 
layer is IMO a terminology question.


Somewhat.  There is a fair amount of science on 
this topic under the heading of process control. 
The only purpose flow control should have in a 
transport protocol is to keep the sender from 
overrunning the receiver.   Getting 
the terminology right can go along way to solving 
the problem.




Although, these distinctions of Network and 
Transport Layer are . . . shall we say, quaint.



Yes, indeed.



Multihoming is fundamentally a routing problem. 
SCTP tries to claim to solve it by changing the 
definition, an old trick.



I am not sure what the two definitions are.
Being more specific would be helpful.


See below, but you did.  ;-)



... Multihoming has nothing to do with what has 
traditionally been called the "Transport Layer."


It is a problem of routing not be able to 
recognize that two points of attachment go to 
the same place. ...


In my understanding, knowing that two locators 
are those of a common destination is the normal 
result from getting these locators by 
translation of an identifier, e.g. a domain name.


I don't believe the routing algorithms translate 
many domain names.  But you are right that a 
domain name is a synonym for a set of IP 
addresses.


Take care,
John



RD



At 14:22 +0100 2008/12/29, Rémi Després wrote:


John,

To pick a local interface for an outgoing 
connection isn't the transport layer, e.g. 
SCTP, well placed to do the job (or some 
intermediate layer function like Shim6)?

Thus, ordinary applications wouldn't need to be concerned.

RD


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: The internet architecture

[michael.dillon]

> Yes, of course.  There are lots of ugly things that can 
> happen.  You don't have to go very far to run into why.  The 
> question is why have we insisted on not doing it right for so long?

Perhaps because others were working on the problems of application
communication without IP addresses. AMQP is one such 
as are all the other protocols that call themselves "message queuing".
XMPP might fall into the same category (RFC refs here
)
but I'm not familiar enough with the details to be sure that it meets
the criteria for unbroken end-to-end communication through IP addressing
change events.

In many ways, this is all a problem of language and history. At the
time many RFCs were written, the world of networking was very different
and very undeveloped. Getting the bareboned basics of networking right
was very, very important. But it was less important to make things
easy for application developers or application users because the very 
fact of a network delivered such great benefits over what came before,
that other problems seemed unworthy of attention. As all of this recedes
into history, the language that we use to speak about technology has
changed
so that terminology which was historically concise, is now a bit vague
and can be interpreted in more than one way. That's because lots of
other
people now use the same language and apply it to their designs,
architectures,
etc.

I think the only way to resolve the question is to publish an Internet 
architecture description in today's context, that explains what the
Internet architecture is, what it isn't, and why it has succeeded in
being what it is. At the same time, one could point to other work
outside
the IETF that has worked on other problems which are related and
intertwined
with Internet architecture, yet separate from it. And if AMQP really
meets
all the requirements of an IP address free protocol, perhaps it should
be
taken under the IETF's wing.

--Michael Dillon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[John Day]

At 11:34 -0500 2008/12/29, John Leslie wrote:

John Day  wrote:

 At 14:22 +0100 2008/12/29, R?mi Despr?s wrote:


 To pick a local interface for an outgoing connection[,]
 isn't the transport layer, e.g. SCTP, well placed to do the job
 (or some intermediate layer function like Shim6)?


 No it isn't Transport's job.  Transport has one and only one purpose:
 end-to-end reliability and flow control.


   I must disagree with John Day.

   I accept "reliability and flow control" as the transport layer's
primary function, but denying it access to multiple interfaces cripples
its ability to perform those functions in a mobility environment.


Transport has nothing to do with mobility.



   And, IMHO, from an architectural viewpoint, multi-homing and mobility
are the same problem.


You are absolutely right.  Mobility is nothing more than dynamic multihoming.

Trying to guess where you are coming from, don't blame Transport for 
TCP's faults.





 "Managing" the resources of the network is the network layer's job.


   That's only partly true, and completely irrelevant.


Highly relevant.  Since only the network layer can manage the network layer.




 Although, these distinctions of Network and Transport Layer are . . .
 shall we say, quaint.


   True, we can't seem to agree to a distinction and stick with it,
but "quaint" is hardly the right word -- it's more like "deja-vu all
over again."


No, quaint. As in "isn't it quaint how people saw things in olden times"


 > Multihoming is fundamentally a routing problem.

   Absolutely not.

   Routing is a function of discovering connectivity and propagating
information about routes to routers that may want to use them.


Boy, if discovering routes and propagating routing information isn't 
a routing  problem, then what is?




   Multihoming is a funtion of maintaining alternate paths in order
to avoid interruptions of connectivity when a primary path hiccups or
becomes congested. (Just like mobility...)


Right.  Routing.


   Multihoming _should_not_ wait for connectivity to fail altogether;
least of all should it wait for connectivity failure to propagate
through an internet.


That is a policy decision that routing is free to make and does.



   We have pretty good routing algorithms for _stable_ networks. We
have to kludge those algorithms to work _at_all_ in unstable networks.
Mobility by its nature _cannot_ be stable. (Multi-homing is most
often done as protection against occasional instability.)


Of course it can.  You just aren't asking the right question.


 > SCTP tries to claim to solve it by changing the definition, an old

 trick.


   Unfair! SCTP was designed for a specific function: it's quite honest
about the design choices. Don't blame its design for other things folks
are trying to use it for.


Only blame ti for things its spec claims it does.


 > Multihoming has nothing to do with what has traditionally been called

 the "Transport Layer."


   If so, perhaps it's time to refine those "definitions" of "Transport
Layer."


Eliminate the transport layer is probably the best thing to do.


 > It is a problem of routing not be able to recognize that two points

 of attachment go to the same place.


   Hardly!

   Routing finds paths between "nodes" using "links". These "nodes"
_are_ points of attachment, not computers (whatever those may be).
Routing _must_ deal in topology, not physical proximity.


Nodes are not points of attachments.  Well, not to the same routing algorithm.




 Portraying it as anything else is just deluding yourself.


   Again, hardly!

   We have been punting entirely too much to "routing" for decades.
There are other perfectly valid ways to divide the problem. And IMHO,
any way that makes the realm of "routing" reside in a "stable" space
is a _better_ paradigm.


O, and BTW, did I say we don't solve multihoming in routers either?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Randy Presuhn]

Hi -

> From: "John Day" 
> To: "Rémi Després" ; "John C Klensin" 
> 
> Cc: "Bryan Ford" ; 
> Sent: Monday, December 29, 2008 7:24 AM
> Subject: Re: The internet architecture
>
> No it isn't Transport's job.  Transport has one
> and only one purpose: end-to-end reliability and
> flow control.
>
> "Managing" the resources of the network is the network layer's job.
>
> Although, these distinctions of Network and
> Transport Layer are . . . shall we say, quaint.
>
> Multihoming is fundamentally a routing problem.

Depends on what one is routing *to* - application,
host, or attachment point.

...
> It is a problem of routing not be able to
> recognize that two points of attachment go to the
> same place.  Portraying it as anything else is
> just deluding yourself.

The multiple-entrance, multiple exit problem could also
be attacked with a variation on good ol' multi-link
procedure, but done just below (or as a sublayer of)
transport, but above (connectionless) network, and
not restrict it to datalink.

Randy


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Brian E Carpenter]

Noel,

On 2008-12-30 05:28, Noel Chiappa wrote:
> > From: John Day 
> 
> > Multihoming is fundamentally a routing problem.

(snip)

> > It is a problem of routing not be able to recognize that two points of
> > attachment go to the same place. Portraying it as anything else is just
> > deluding yourself.
> 
> I would agree with this, except I defer to the 'get down off an elephant'
> principle. If both points of attachment are bound to a single transport level
> entity, then it ought to be relatively easy, and not involve the routing at
> all, to detect that both points of attachment lead to the same entity.

It ought to be, but unfortunately we have confounded the transport entity
namespace with the network entity namespace with the point of attachment
namespace.

Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[John Leslie]

John Day  wrote:
> At 11:34 -0500 2008/12/29, John Leslie wrote:
>> 
>> I accept "reliability and flow control" as the transport layer's
>> primary function, but denying it access to multiple interfaces cripples
>> its ability to perform those functions in a mobility environment.
> 
> Transport has nothing to do with mobility.

   To whatever extent we accept the existence of "transport" for
stationary computers, we must allow it for mobile computers.

   I think we're arguing semantics here, without agreeing on what we
mean by "transport". I'd much rather continue that argument on a different
mailing-list.

> Trying to guess where you are coming from, don't blame Transport for 
> TCP's faults.

   TCP has many faults, only some of which are related to its "transport
layer" functions.

   Where I'm coming from, BTW, is a long series of primal screams when
I hear someone proposing how to deal with transport issues in a
routing protocol.

>>> Although, these distinctions of Network and Transport Layer are . . .
>>> shall we say, quaint.
>>
>> True, we can't seem to agree to a distinction and stick with it,
>> but "quaint" is hardly the right word -- it's more like "deja-vu all
>> over again."
> 
> No, quaint. As in "isn't it quaint how people saw things in olden times"

   But, IMHO, we _never_have_ seen network-vs-transport in a consistent
way.

>>> Multihoming is fundamentally a routing problem.
>>
>> Absolutely not.
>>
>> Routing is a function of discovering connectivity and propagating
>> information about routes to routers that may want to use them.
> 
> Boy, if discovering routes and propagating routing information isn't 
> a routing  problem, then what is?

   Multihoming (or mobility, if you prefer) isn't about "discovering"
alternate connectivity: it's about verifying that something arriving
via a different path is in fact controlled by the same process as
something we're already communicating with. That is _not_ a routing
issue -- routing merely attempts to deliver packets.

>> Multihoming is a funtion of maintaining alternate paths in order
>> to avoid interruptions of connectivity when a primary path hiccups or
>> becomes congested. (Just like mobility...)
> 
> Right.  Routing.

   Even if we were to accept a flooding paradigm for routing (and send
every packet out every interface), multihoming would still require
sorting out which packets to trust.

>> Multihoming _should_not_ wait for connectivity to fail altogether;
>> least of all should it wait for connectivity failure to propagate
>> through an internet.
> 
> That is a policy decision that routing is free to make and does.

   Although routing _does_ make such decisions, architecturally that's
noise, not a native "network layer" function. Network-layer is about
getting packets through a network of networks _at_all_ -- not about
managing everyone's Quality-of-Service wishlists. "Efficiency" issues
in routing are there to keep routing from breaking, for example by
routing packets in a loop until TTL is exhausted.

>> We have pretty good routing algorithms for _stable_ networks. We
>> have to kludge those algorithms to work _at_all_ in unstable networks.
>> Mobility by its nature _cannot_ be stable. (Multi-homing is most
>> often done as protection against occasional instability.)
> 
> Of course it can.  You just aren't asking the right question.

   Feel free to correct me -- what question should I be asking?

>>> Multihoming has nothing to do with what has traditionally been called
>>> the "Transport Layer."
>>
>> If so, perhaps it's time to refine those "definitions" of "Transport
>> Layer."
> 
> Eliminate the transport layer is probably the best thing to do.

   I'd be happy to talk about that -- on the  list.

>> Routing finds paths between "nodes" using "links". These "nodes"
>> _are_ points of attachment, not computers (whatever those may be).
>> Routing _must_ deal in topology, not physical proximity.
> 
> Nodes are not points of attachments. Well, not to the same routing 
> algorithm.

   To a routing algorithm, "nodes" are "nodes", period. True.

   But in the Internet, IP addresses _are_ points of attachment, and
network-layer routing finds paths between "points of attachment".

>> We have been punting entirely too much to "routing" for decades.
>> There are other perfectly valid ways to divide the problem. And IMHO,
>> any way that makes the realm of "routing" reside in a "stable" space
>> is a _better_ paradigm.
> 
> O, and BTW, did I say we don't solve multihoming in routers either?

   Not this week... ;^)

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: The internet architecture

[Christian Huitema]

> > I would agree with this, except I defer to the 'get down off an
> elephant'
> > principle. If both points of attachment are bound to a single
> transport level
> > entity, then it ought to be relatively easy, and not involve the
> routing at
> > all, to detect that both points of attachment lead to the same entity.
>
> It ought to be, but unfortunately we have confounded the transport
> entity
> namespace with the network entity namespace with the point of attachment
> namespace.

Not really. Many applications are actively managing their network connections, 
and for a good reason. A network connection is not an interface to an abstract 
"unified network". On the contrary, a network interface implements a contract 
with a specific network.

Take the example of a laptop with Bluetooth, Wi-Fi, WIMAX and 3G. Four 
connections, with four different providers. Wi-Fi, through the access point, 
communicates with a broadband provider, maybe a cable company such as Comcast. 
WIMAX communicates with the Internet through a wireless provider, maybe 
Clearwire. 3G also offer some kind of Internet access, possibly through a 
different provider such as AT&T. And Bluetooth typically does not communicate 
with the Internet, but provides access to some local devices. You will note 
that the different providers have different rules for managing traffic. Behind 
each interface lies a different contract, a different type of service.

Is it possible to manage all these interfaces as if they were a single abstract 
point of attachment? Maybe. That would require a common management system. Can 
that management system be part of "the network"? Frankly, I doubt it. The 
management system will have to make arbitration between different services, 
deciding which part of the traffic goes which way. These decisions have 
economic consequences. Do you really believe that different providers will 
delegate these economic decisions to some kind of cooperative distributed 
system? If that was realistic, we would have network wide QOS by now...

On the other hand, the end system is in a very good position to implement these 
arbitrations. It has direct access to the requirement of the applications, and 
to the terms of each specific interface contract. Moreover, it can actually 
measure the quality of the offered service, allowing for informed real time 
decisions.

We can debate which part of the end system should implement these decisions, 
whether it should be the application or a common transport layer. I can see 
arguments either way. But the business reality essentially precludes an 
implementation in the network layer. Even if we did reengineer the network 
layer to implement a clean separation between identifiers and locators, the 
business reality will still be there. We will end up with separate identifiers 
for the different "provider contracts", and applications, or the transport 
layers, will have to arbitrage between these contracts.

-- Christian Huitema



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture - pointer to RRG discussion

[Robin Whittle]

Short version:   Please contribute to the IRTF Routing Research Group
 discussions on how to devise a new Internet
 architecture (including by adding to the current
 architecture) to solve the routing scaling problem.

Hi John and All,

This discussion includes debate about whether in a new Internet
architecture, the responsibility for handling network-centric
problems should in future be handled by hosts.  These network-centric
 real-time events, problems and responsibilities include:

 1 - Multihoming.

 2 - Traffic engineering.

 3 - Portability of address space - or some other, yet to be
 invented, approach which has the same effect of making it easy
 to choose another ISP without the disruption, cost etc.

Please take a look at the current discussions in the IRTF Routing
Research Group.  The RRG has been charged with the responsibility of
recommending to the IESG what sort of architectural changes should be
made to the Internet (really, the IPv4 Internet and the IPv6
Internet) to solve the routing scaling problem.  The deadline is
March 2009.

RRG mailing list archives, wiki and charter:

 http://www.irtf.org/pipermail/rrg/
 http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
 http://www.irtf.org/charter?gtype=rg&group=rrg

The RAWS workshop (Amsterdam October 2006):

 http://tools.ietf.org/html/rfc4984
 http://www.iab.org/about/workshops/routingandaddressing/


I wrote a critique of any solution which pushes new responsibilities
onto hosts which concern things which occur in the network:

 Fundamental objections to a host-based scalable routing solution
 http://www.irtf.org/pipermail/rrg/2008-November/000271.html

Bill Herrin has a page which attempts to list the various approaches
to solving the routing scaling problem:

 http://bill.herrin.us/network/rrgarchitectures.html

I think the problem definition there is biased towards the notion
that the solution is to have hosts take on new functions, including
with changes to stacks, APIs and applications.  I wrote some
additional text which I think provides a more complete problem
description:

 http://www.irtf.org/pipermail/rrg/2008-December/000525.html

Also of interest is a recent paper contrasting network centric
core-edge separation schemes with host-centric "elimination" schemes:

  Towards a Future Internet Architecture: Arguments for Separating
  Edges from Transit Core

  Dan Jen (UCLA), Lixia Zhang (UCLA), Lan Wang (University of
  Memphis), Beichuan Zhang (University of Arizona)

  (HotNets-VII) Calgary, Alberta, Canada October 6-7, 2008
  http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

Bill is currently calling for RRG members to form strong consensus on
rejecting one or more solution strategies.  (Msg 000554.)  The types
of strategy are (with my descriptions for A, B and C):

Strategy A:

  Network-based core-edge separation schemes, including LISP, APT
  Ivip, TRRP and Six-One Router.  (See the RRG wiki page for links.)

Strategy B:

  Host-centric elimination schemes.  "Elimination" means all end-user
  network addresses are subsets of ISP prefixes.  Only ISP prefixes
  are advertised in the interdomain routing system.

  See Brian Carpenter's message on how this is "unworkable for IPv4
  and very close to the plan of record for IPv6" - except that
  IPv6 doesn't provide multihoming (session survival when the
  currently used ISP-provided address becomes unusable).

   http://www.irtf.org/pipermail/rrg/2008-December/000577.html

Strategy C:

  New interdomain routing system arrangements, including for
  instance: geographical aggregation or compact routing.
  (A critique of compact routing: http://arxiv.org/abs/0708.2309.)

Strategy D:

  "Use plain old BGP for the RIB. Algorithmically compress the FIB in
  each router."

Strategy E:

  "Make no routing architecture changes. Instead, create a billing
  system through which the folks running core routers are paid by the
  folks announcing each prefix to carry those prefixes. Let economics
  suppress growth to a survivable level."

Strategy F:

  "Do nothing. (RFC 1887 § 4.4.1)"


My message calling for strong consensus in rejecting Strategies B, C,
D, E and F:

  http://www.irtf.org/pipermail/rrg/2008-December/000565.html



  - Robinhttp://www.firstpr.com.au/ip/ivip/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Brian E Carpenter]

Hi Christian,

On 2008-12-30 11:55, Christian Huitema wrote:
>>> I would agree with this, except I defer to the 'get down off an
>> elephant'
>>> principle. If both points of attachment are bound to a single
>> transport level
>>> entity, then it ought to be relatively easy, and not involve the
>> routing at
>>> all, to detect that both points of attachment lead to the same entity.
>> It ought to be, but unfortunately we have confounded the transport
>> entity
>> namespace with the network entity namespace with the point of attachment
>> namespace.
> 
> Not really. Many applications are actively managing their network 
> connections, and for a good reason. A network connection is not an interface 
> to an abstract "unified network". On the contrary, a network interface 
> implements a contract with a specific network.

It seems to me that you're agreeing with me. It's exactly because the three
namespaces I mentioned are mashed together by TCP/IP that applications have
to do what you describe, rather than just saying "open a connection to
Christian's laptop."

Brian

> Take the example of a laptop with Bluetooth, Wi-Fi, WIMAX and 3G. Four 
> connections, with four different providers. Wi-Fi, through the access point, 
> communicates with a broadband provider, maybe a cable company such as 
> Comcast. WIMAX communicates with the Internet through a wireless provider, 
> maybe Clearwire. 3G also offer some kind of Internet access, possibly through 
> a different provider such as AT&T. And Bluetooth typically does not 
> communicate with the Internet, but provides access to some local devices. You 
> will note that the different providers have different rules for managing 
> traffic. Behind each interface lies a different contract, a different type of 
> service.
> 
> Is it possible to manage all these interfaces as if they were a single 
> abstract point of attachment? Maybe. That would require a common management 
> system. Can that management system be part of "the network"? Frankly, I doubt 
> it. The management system will have to make arbitration between different 
> services, deciding which part of the traffic goes which way. These decisions 
> have economic consequences. Do you really believe that different providers 
> will delegate these economic decisions to some kind of cooperative 
> distributed system? If that was realistic, we would have network wide QOS by 
> now...
> 
> On the other hand, the end system is in a very good position to implement 
> these arbitrations. It has direct access to the requirement of the 
> applications, and to the terms of each specific interface contract. Moreover, 
> it can actually measure the quality of the offered service, allowing for 
> informed real time decisions.
> 
> We can debate which part of the end system should implement these decisions, 
> whether it should be the application or a common transport layer. I can see 
> arguments either way. But the business reality essentially precludes an 
> implementation in the network layer. Even if we did reengineer the network 
> layer to implement a clean separation between identifiers and locators, the 
> business reality will still be there. We will end up with separate 
> identifiers for the different "provider contracts", and applications, or the 
> transport layers, will have to arbitrage between these contracts.
> 
> -- Christian Huitema
> 
> 
> 
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: The internet architecture

[Christian Huitema]

> >> It ought to be, but unfortunately we have confounded the transport
> >> entity
> >> namespace with the network entity namespace with the point of
> attachment
> >> namespace.
> >
> > Not really. Many applications are actively managing their network
> connections, and for a good reason. A network connection is not an
> interface to an abstract "unified network". On the contrary, a network
> interface implements a contract with a specific network.
>
> It seems to me that you're agreeing with me. It's exactly because the
> three
> namespaces I mentioned are mashed together by TCP/IP that applications
> have
> to do what you describe, rather than just saying "open a connection to
> Christian's laptop."

If "Christian's laptop" is the "transport" name space, and if the network 
entity namespace use different network entity names to designate the various 
"network contracts", then, yes, we probably agree. Although I am not sure that 
we should place too much emphasis on the name of physical entities like 
"Christian's laptop". What if the application process migrates from my laptop 
to my desktop?

-- Christian Huitema



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Tony Finch]

On Mon, 29 Dec 2008, Noel Chiappa wrote:
>
> I have been thinking this for some time too, and it's especially
> true/clear when the multi-homing in question is site multi-homing, and
> not host-multihoming (which is much rarer, is my impression).

Most networkable consumer electronics ships with at least two network
interfaces. Host multihoming is only rare because it doesn't work.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
WIGHT PORTLAND: SOUTHEAST BACKING EAST 3 OR 4, OCCASIONALLY 5. SLIGHT,
OCCASIONALLY MODERATE IN PORTLAND. MAINLY FAIR. MODERATE OR GOOD, OCCASIONALLY
POOR.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Marshall Eubanks]

On Dec 29, 2008, at 10:02 PM, Tony Finch wrote:


On Mon, 29 Dec 2008, Noel Chiappa wrote:


I have been thinking this for some time too, and it's especially
true/clear when the multi-homing in question is site multi-homing,  
and

not host-multihoming (which is much rarer, is my impression).


Most networkable consumer electronics ships with at least two network
interfaces. Host multihoming is only rare because it doesn't work.


Why do you say it doesn't work ? I have found host multihoming to be  
very useful at
times, especially if the local network uses several address blocks for  
whatever reason. (Note that of course

there is still a router routing this.)

And, if you use a software based router (which many do) that is  
strictly speaking host multihoming.


Regards
Marshall




Tony.
--
f.anthony.n.finchhttp://dotat.at/
WIGHT PORTLAND: SOUTHEAST BACKING EAST 3 OR 4, OCCASIONALLY 5. SLIGHT,
OCCASIONALLY MODERATE IN PORTLAND. MAINLY FAIR. MODERATE OR GOOD,  
OCCASIONALLY

POOR.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RFC 5378 Contributor License Form

[TSG]

Ray Pelletier wrote:

All
What does that mean to the contractual relationship to the IETF's 
process for those IP's being evoplved inside it? Seems to me that place 
a stop on anything places a stop on everything.


Todd


The trustees are aware of the problems with respect to the RFC 5378 
implementation and possible consequences with respect to the license. 
Pending a further analysis, and possible modification to the license, 
we have taken the current license off-line.


You may also expect a proposal for a temporary workaround to the 
problems identified by the implementation of RFC 5378. That proposal 
is currently reviewed by the trust and will be posted as an Internet 
Draft soon.


Ray Pelletier
IAD/Trustee
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



Internal Virus Database is out of date.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 12/15/2008 5:04 PM


  


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf