Short version:    Interesting report on Internet traffic patterns.

                  Trying to use the EID/SPI address as a purely
                  local identifier, with the same value to be
                  re-used in various end-user networks, is
                  incompatible with CES, since it must be globally
                  unique.

                  IPv4 will be _central_ for a long time to come.

Hi patte,

You wrote:

>>> A cookie is an identifier that is decoupled from the address
>>> space and network layer, the more these kind of applications
>>> there is deployed the easier it would be to change the network
>>> and address architecture.
>>
>> Yes, but this is just client-server applications.
>
> Very true, it is just one application.
> But it is causing about 52% of the Internet traffic and increasing
> Have a look on slide 22 at
 
http://www.nanog.org/meetings/nanog47/presentations/Monday/Labovitz_ObserveReport_N47_Mon.pdf

> But once you get into enterprises the traffic profile is different

Thanks for pointing me to this most interesting report.  I am glad to
see P2P traffic dropping in favour of "direct download" file sharing.
 Having all those bytes flowing upstream in DSL cable systems was
really bad.  DSL upstream links have limited RF bandwidth - 10 or 20
MHz or so - and are very low efficiency, such as 1 bit per Hz,
whereas downstream is 6 to 8 bits per Hz, with many 6 to 8MHz bands
available.  DSL upstream is less efficient and more constrained too,
but not as bad as HFC cable.

I am not surprised that "Web" traffic, at 52% and rising, dominates
the traffic stats.  But the volume of packets doesn't necessarily
correlate fully with the value of the application.


Quoting yourself, Noel, yourself and Noel again, you wrote:

>>>> Ah, no - LEID's are globally visible, and globally unique.
>>
>>> Do they really need to be globally visible and globally unique in the
>>> future?
>>
>> Yes - they need to be globally visible because they are the names that
>> endpoints use to identify each other, and you may want to talk to another
>> endpoint anywhere (hence the need for global scope).
>>
> If you take the core-edge philosophy and apply that on the address
> space - creating a hierarchical address space the endpoints can still
> be identified though they use the same edge space. 

I wouldn't describe CES architectures such as LISP as involving
"hierarchical address space", so I am not sure what you are referring
to.  How could the "edge" addresses of LISP (EIDs) or Ivip (SPI
addresses) be used so that two hosts could be separately identified,
separately used for communications or whatever, when they are on the
same "edge" address?

The "edge" addresses are a subset of the global unicast address
space.  Unless used as anycast addresses, any such address - in
either the "core" or "edge" subset - can be used to identify only one
host.


> With LISP terms, if
> the RLOC is telling the attachment point to Internet and the EID is
> telling the attachment point at the local network you have a two level
> address space. And the local network address space can be reused if
> the global address space is unique - similar as in PSTN but without
> geographical boundaries, it should follow as much as possible the AS
> and RIR structures that is in place (some trade offs are needed).

Then you are no longer describing LISP or any other CES arrangement.

The EID is indeed used within the end-user network to specifically
identify the destination host, but the whole purpose of CES is to
make that address both globally reachable, and able to be used via
any ISP.

The first requirement - global reachability - means that the EID is
globally unique.

(Skipping some of what you wrote.)

>>> IPv4 will be around for a very long time - especially in the old
>>> economies
>>
>> My point was stronger than that, actually - I was arguing that IPv4 addresses
>> will be _central_ for a long time to come.
> 
> You too, I hadn't the courage to state that :-)

I agree with you both.

  - Robin

_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to