Re: [Int-area] Where/How is the features innovation happening?

[Dino Farinacci]

> As a network layer person I personally find this a pretty sad situation, and 
> I would like it to be otherwise. But the capital markets don't listen to me. 
> They are busy talking up the content and cloud folk who are busy pushing out 
> replicated content ever closer to the consumer, and they neither care nor 
> value anything else.

I feel the same way and have for almost 2 decades. That is the reason I focus 
new designs and use-cases using overlays because it is easier to control the 
application edge and just assume the underlay can never and will never change 
for the new use-cases.

Dino

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Dino Farinacci]

> If we care about the peer-to-peer property, varying addresses require a 
> rendezvous process based on a non-varying identifier. It's then the latter 
> that becomes the handle for surveillance and forensics. The real impact of 
> CGNAT is to push that factoid into surveillance models; it gives IPv4 the 
> same privacy assist that temporary addresses give IPv6.

Hosts talk to hosts, I don't care if they are in a data center or two clients. 
You don't have to distinguish and certainly shouldn't design an address 
algorithm to distinguish.

As for surveliience and privacy, you can't have both. So pick one.

And Luigi, you shouldn't trust the devices that are close to you. Even if you 
manage them you can't trust the vendors that make them.

Dino

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] IP parcels

[to...@strayalpha.com]

Hi, Fred,

I’m first concerned at the use of an IP option at all, due to the problems with 
*any* options forcing processing to slow-path.

From TCP’s viewpoint, it seems like you’ve just created a nightmare for SACK 
and ECN, basically because you will encourage drops of large bursts of packets.

This will also increase the bustiness of TCP, i.e., rather than letting the 
ACKs support pacing.

Any part of the system that currently coalesces TCP packets is likely to 
generate errors here, because they might see only the first TCP segment.

However, AFAICT the most significant consideration is that  the issue with 
per-packet performance is at the TCP and UDP layers, not as much at the IP 
layer.

So what problem is this trying to solve?

Joe
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 17, 2021, at 5:06 PM, Templin (US), Fred L  
> wrote:
> 
> Here's one that should help with shipping, just in time for Christmas. Thanks
> to everyone for the past and future list exchanges.
> 
> Fred
> 
> -Original Message-
> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Friday, December 17, 2021 5:00 PM
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-templin-intarea-parcels-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>Title   : IP Parcels
>Author  : Fred L. Templin
>   Filename: draft-templin-intarea-parcels-00.txt
>   Pages   : 8
>   Date: 2021-12-17
> 
> Abstract:
>   IP packets (both IPv4 and IPv6) are understood to contain a unit of
>   data which becomes the retransmission unit in case of loss.  Upper
>   layer protocols such as the Transmission Control Protocol (TCP)
>   prepare data units known as "segments", with traditional arrangements
>   including a single segment per packet.  This document presents a new
>   construct known as the "IP Parcel" which permits a single packet to
>   carry multiple segments.  The parcel can be opened at middleboxes on
>   the path with the included segments broken out into individual
>   packets, then rejoined into one or more repackaged parcels to be
>   forwarded further toward the final destination.  Reordering of
>   segments within parcels is unimportant; what matters is that the
>   number of parcels delivered to the final destination should be kept
>   to a minimum, and that loss or receipt of individual segments (and
>   not parcel size) determines the retransmission unit.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-00
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] IP parcels

[Templin (US), Fred L]

Here's one that should help with shipping, just in time for Christmas. Thanks
to everyone for the past and future list exchanges.

Fred

-Original Message-
From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Friday, December 17, 2021 5:00 PM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-templin-intarea-parcels-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : IP Parcels
Author  : Fred L. Templin
Filename: draft-templin-intarea-parcels-00.txt
Pages   : 8
Date: 2021-12-17

Abstract:
   IP packets (both IPv4 and IPv6) are understood to contain a unit of
   data which becomes the retransmission unit in case of loss.  Upper
   layer protocols such as the Transmission Control Protocol (TCP)
   prepare data units known as "segments", with traditional arrangements
   including a single segment per packet.  This document presents a new
   construct known as the "IP Parcel" which permits a single packet to
   carry multiple segments.  The parcel can be opened at middleboxes on
   the path with the included segments broken out into individual
   packets, then rejoined into one or more repackaged parcels to be
   forwarded further toward the final destination.  Reordering of
   segments within parcels is unimportant; what matters is that the
   number of parcels delivered to the final destination should be kept
   to a minimum, and that loss or receipt of individual segments (and
   not parcel size) determines the retransmission unit.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-00


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Tom Herbert]

On Fri, Dec 17, 2021 at 2:22 PM Brian E Carpenter
 wrote:
>
> On 18-Dec-21 10:58, Tom Herbert wrote:
> > On Fri, Dec 17, 2021 at 12:07 PM to...@strayalpha.com
> >  wrote:
> >>
> >> Globally unique != static.
> >>
> >> They can be randomized and varied over time, e.g., as are Ethernet MAC
> addresses, exactly for the reasons you note.
> >
> > I would agree with that if the time to randomize is basically so small
> > that a client can use a unique and un-correlatable address for each
> > connection. Given the data collection abilities and compute resources
> > available to those that want to engage in surveillance, any time for
> > randomizing addresses, be it a day, an hour, or a few minutes, that is
> > greater than this minimum only provides a false sense of security with
> > respect to trying to prevent third parties from making correlations
> > about the sender's identity between different flows on the Internet.
> > Interestingly, CGNAT with enough users behind it can provide these
> > properties (attested by the fact the law enforcement has complained
> > about it).
>
> If we care about the peer-to-peer property, varying addresses require a 
> rendezvous process based on a non-varying identifier. It's then the latter
> that becomes the handle for surveillance and forensics. The real impact of 
> CGNAT is to push that factoid into surveillance models; it gives IPv4 the 
> same privacy assist that temporary addresses give IPv6.

Brian,

I believe CGNAT is better than IPv6 in terms of privacy in addressing.
In fact one might argue that IPv4 provides better privacy and security
than IPv6 in this regard. Temporary addresses are not single use which
means the attacker can correlate addresses from a user between
unrelated flows during the quantum the temporary address is used. When
a user changes their address, the attacker can continue monitoring if
it is signaled that the address changed. Here is a fairly simple
exploit I derived to do that (from
draft-herbert-ipv6-prefix-address-privacy-00).

The exploit is:
  o An attacker creates an "always connected" app that provides some
seemingly benign service and users download the app.
  o The app includes some sort of persistent identity. For instance,
this could be an account login.
  o The backend server for the app logs the identity and IP address
of a user each time they connect
  o When an address change happens, existing connections on the user
device are disconnected. The app will receive a notification and
immediately attempt to reconnect using the new source address.
  o The backend server will see the new connection and log the new
IP address as being associated with the specific user. Thus,
the server has
a real-time record of users and the IP address they are using.
  o The attacker intercepts packets at some point in the Internet.
The addresses in the captured packets can be time correlated
with the server database to deduce identities of parties in
communications that are unrelated to the app.

The only way I see to mitigate this sort of surveillance is single use
addresses. That is effectively what  CGNAT can provide.

Tom

>
> So perhaps what we need is a surveillance-proof rendezvous mechanism.
>
> Brian
>
> >
> > Tom
> >
> >>
> >> Joe
> >>
> >> —
> >> Joe Touch, temporal epistemologist
> >> www.strayalpha.com
> >>
> >> On Dec 17, 2021, at 11:46 AM, Brian E Carpenter 
> >>  wrote:
> >>
> >> On 18-Dec-21 07:48, Geoff Huston wrote:
> >> ...
> >>
> >> So, to repurpose some graffiti from the 1970’s, we need globally unique 
> >> addresses like fish need bicycles! :-)
> >>
> >>
> >> They have residual value for surveillance and possibly other forensic 
> >> uses, which may of course be actively harmful to the user.
> >>
> >> But on the other hand, while what you say about economics is undoubtedly 
> >> true, don't we want to keep the peer-to-peer option open *as a matter of 
> >> principle*? After all, we still have that option for phone calls, even
> though it's now a minority usage pattern for mobile devices.
> >>
> >> Brian
> >>
> >> ___
> >> Int-area mailing list
> >> Int-area@ietf.org
> >> https://www.ietf.org/mailman/listinfo/int-area
> >>
> >>
> >> ___
> >> Int-area mailing list
> >> Int-area@ietf.org
> >> https://www.ietf.org/mailman/listinfo/int-area
>

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Geoff Huston]

> But on the other hand, while what you say about economics is undoubtedly 
> true, don't we want to keep the peer-to-peer option open *as a matter of 
> principle*? After all, we still have that option for phone calls, even though 
> it's now a minority usage pattern for mobile devices.
> 


How much money are consumers willing to fork out as a premium for a matter of 
principle? The answer is uncomfortable, I suspect.

I find this world we’ve backed into about as crappy and unpleasant as anyone 
else on this int-area list, and like many others I wish it were otherwise. But 
as many folk have said in the past, when assessing where we are and what to do 
about it, the trick is not in seeing what's around us - everyone sees that. The 
trick is to believe what we see. The phone companies saw their destruction but 
simply could not believe it. There are many such examples.

The commercial marketplace, in striving for bigger, faster, and cheaper has 
simply cut out the network from the picture and is trying to take replicated 
content as close as it can to the user. The economic imperatives that have 
driven us to this place are, in retrospect, inescapable. Yes, a lot has been 
discarded along the way, including every protocol except HTTPS, but the harsh 
rule is that if not enough consumers are prepared to pay for it, directly or 
indirectly, then it just doesn't happen any more.

There is innovation happening to return to the subject line of this thread, but 
the innovation is happening in those places where there is money and a certain 
impatience to shift things around, and in the last decade or so that is heading 
up into the world of content and applications. The lower layers, including 
platform and network are not only commoditised, but steadily ossifying. There 
is just no money and no desire to shake up these lower layers right now, nor in 
the immediate to medium term future.

As a network layer person I personally find this a pretty sad situation, and I 
would like it to be otherwise. But the capital markets don't listen to me. They 
are busy talking up the content and cloud folk who are busy pushing out 
replicated content ever closer to the consumer, and they neither care nor value 
anything else.

Geoff
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Brian E Carpenter]

On 18-Dec-21 10:58, Tom Herbert wrote:

On Fri, Dec 17, 2021 at 12:07 PM to...@strayalpha.com
 wrote:


Globally unique != static.

They can be randomized and varied over time, e.g., as are Ethernet MAC 

addresses, exactly for the reasons you note.


I would agree with that if the time to randomize is basically so small
that a client can use a unique and un-correlatable address for each
connection. Given the data collection abilities and compute resources
available to those that want to engage in surveillance, any time for
randomizing addresses, be it a day, an hour, or a few minutes, that is
greater than this minimum only provides a false sense of security with
respect to trying to prevent third parties from making correlations
about the sender's identity between different flows on the Internet.
Interestingly, CGNAT with enough users behind it can provide these
properties (attested by the fact the law enforcement has complained
about it).


If we care about the peer-to-peer property, varying addresses require a rendezvous process based on a non-varying identifier. It's then the latter 
that becomes the handle for surveillance and forensics. The real impact of CGNAT is to push that factoid into surveillance models; it gives IPv4 the same privacy assist that temporary addresses give IPv6.


So perhaps what we need is a surveillance-proof rendezvous mechanism.

   Brian



Tom



Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

On Dec 17, 2021, at 11:46 AM, Brian E Carpenter  
wrote:

On 18-Dec-21 07:48, Geoff Huston wrote:
...

So, to repurpose some graffiti from the 1970’s, we need globally unique 
addresses like fish need bicycles! :-)


They have residual value for surveillance and possibly other forensic uses, 
which may of course be actively harmful to the user.

But on the other hand, while what you say about economics is undoubtedly true, don't we want to keep the peer-to-peer option open *as a matter of principle*? After all, we still have that option for phone calls, even 

though it's now a minority usage pattern for mobile devices.


Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Tom Herbert]

On Fri, Dec 17, 2021 at 12:07 PM to...@strayalpha.com
 wrote:
>
> Globally unique != static.
>
> They can be randomized and varied over time, e.g., as are Ethernet MAC 
> addresses, exactly for the reasons you note.

I would agree with that if the time to randomize is basically so small
that a client can use a unique and un-correlatable address for each
connection. Given the data collection abilities and compute resources
available to those that want to engage in surveillance, any time for
randomizing addresses, be it a day, an hour, or a few minutes, that is
greater than this minimum only provides a false sense of security with
respect to trying to prevent third parties from making correlations
about the sender's identity between different flows on the Internet.
Interestingly, CGNAT with enough users behind it can provide these
properties (attested by the fact the law enforcement has complained
about it).

Tom

>
> Joe
>
> —
> Joe Touch, temporal epistemologist
> www.strayalpha.com
>
> On Dec 17, 2021, at 11:46 AM, Brian E Carpenter  
> wrote:
>
> On 18-Dec-21 07:48, Geoff Huston wrote:
> ...
>
> So, to repurpose some graffiti from the 1970’s, we need globally unique 
> addresses like fish need bicycles! :-)
>
>
> They have residual value for surveillance and possibly other forensic uses, 
> which may of course be actively harmful to the user.
>
> But on the other hand, while what you say about economics is undoubtedly 
> true, don't we want to keep the peer-to-peer option open *as a matter of 
> principle*? After all, we still have that option for phone calls, even though 
> it's now a minority usage pattern for mobile devices.
>
>Brian
>
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>
>
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[to...@strayalpha.com]

Globally unique != static.

They can be randomized and varied over time, e.g., as are Ethernet MAC 
addresses, exactly for the reasons you note.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 17, 2021, at 11:46 AM, Brian E Carpenter  
> wrote:
> 
> On 18-Dec-21 07:48, Geoff Huston wrote:
> ...
>> So, to repurpose some graffiti from the 1970’s, we need globally unique 
>> addresses like fish need bicycles! :-)
> 
> They have residual value for surveillance and possibly other forensic uses, 
> which may of course be actively harmful to the user.
> 
> But on the other hand, while what you say about economics is undoubtedly 
> true, don't we want to keep the peer-to-peer option open *as a matter of 
> principle*? After all, we still have that option for phone calls, even though 
> it's now a minority usage pattern for mobile devices.
> 
>Brian
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Brian E Carpenter]

On 18-Dec-21 07:48, Geoff Huston wrote:
...

So, to repurpose some graffiti from the 1970’s, we need globally unique 
addresses like fish need bicycles! :-)


They have residual value for surveillance and possibly other forensic uses, 
which may of course be actively harmful to the user.

But on the other hand, while what you say about economics is undoubtedly true, 
don't we want to keep the peer-to-peer option open *as a matter of principle*? 
After all, we still have that option for phone calls, even though it's now a 
minority usage pattern for mobile devices.

Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Geoff Huston]

> On 17 Dec 2021, at 9:35 am, Dino Farinacci  wrote:
> 
>> If we don't want to share a common transmission resource, then why do we 
>> need globally unique addresses to use in IP packet headers? Locally unique 
>> addresses would do just as well.
> 
> Just to answer this question specifically. We may not need globally unique 
> addresses. But I need a unique address for anyone I want to talk to and I 
> don't care what transmission networks my packets traverse.
> 
> Therefore, we need unique addresses. However, lets say an address is 24 bits 
> long and we use a random number to generate the address. It is unlikely that 
> there will be an address collision for all the things I want to talk to. So 
> to me I get my unique address. Is it globally unique, well no, but maybe it 
> doesn't have to be. 
> 
> But there will be hosts that want to talk to everyone in the world or at 
> least beyond an address collision domain, so we default for the desire to 
> want/need globally unique addresses. So simply using a random number 
> generator for an IPv6 address may get us there and work sufficiently. 
> 
> Comments?


I have no idea when I last sent a packet from my client host to any other 
client host. Somewehere is the massive stream of packets that come from the 
data centres nearby is a lonesome packet that made its way through. maybe. or 
maybe not. Such packets are statistically insignificant in volume, and, more 
importantly, economically insignificant.

This latter observation is the critical one. QoS lost its way in the public 
Internet because it was obvious that it was costing far more than the marginal 
revenue it was raising. (It survived in enterprise environment largely because 
in enterprise environments then network is not treated as an isolated cost 
centre.)

If all my packets come from highly replicated data centres then all that 
matters is my endpoint identity (i.e. address) relative to that data centre. A 
unique global identity is a pointless (and expensive) luxury.

So, to repurpose some graffiti from the 1970’s, we need globally unique 
addresses like fish need bicycles! :-)


regards,

   Geoff


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [EXTERNAL] Re: Side meeting follow-up: What exact features do we want from the Internet?

[Templin (US), Fred L]

Alex, I do not think there is any problem for QUIC. IPv6 Next Header field only 
takes
a value for UDP; it does not take a value for QUIC. It is QUIC's job to make 
sure that
everything beyond the UDP header is aligned properly for its own purposes.

Fred

> -Original Message-
> From: Alexandre Petrescu [mailto:alexandre.petre...@gmail.com]
> Sent: Friday, December 17, 2021 12:53 AM
> To: Templin (US), Fred L ; int-area@ietf.org
> Subject: [EXTERNAL] Re: [Int-area] Side meeting follow-up: What exact 
> features do we want from the Internet?
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> 
> 
> Le 15/12/2021 à 19:56, Templin (US), Fred L a écrit :
> > Alex,
> >
> >> A new feature in an ALv2 would be that instead of just a
> >> frag-reassembly from sender to receiver, one would consider
> >> group-degroup of packets too, to reduce overhead.  If this too is
> >> not already there in ALs.
> >
> > The adaptation layer is that layer below the network layer but above
> > the data link layer. The group-degroup functions you are referring to
> > would apply at the adaptation layer send-side entry or receive-side
> > exit.
> 
> Yes, from a topology perspective that's where 'group-degroup' could sit.
> 
>  From an ISO layer perspective a 'group-degroup' would probably sit in an
> adaptation layer, below IP and above data link layer.
> 
> A 'group-degroup' function can also be seen in the jumbogram software
> mechanism, rather than in the frag-defrag mechanism.  The jumbogram
> seems to be in the app layer (ApL?) whereas frag-defrag in the
> adaptation layer (AdL?).
> 
> This makes wonder whether a group-degroup function would go into ApL or
> rather in the AdL?
> 
> Whether or not the modern QUIC, rather than the older UDP and TCP,
> includes a jumbogram mechanism and potentially group-degroup functions
> could be explored.  Because IPv6 jumbograms are specified for TCP and
> UDP (RFC2675 "jumbograms"), but not for QUIC.  This could further hint
> on which layer is best for a group-degroup function, AdL or ApL.
> 
> Alex
> 
>   Those
> > sorts of capabilities are already out in the wild in some systems,
> > but I have not seen a formal IETF spec yet. This seems like something
> > that could be mentioned in an adaptation layer spec.
> >
> > Fred

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

[to...@strayalpha.com]

Hi, Alex,

> On Dec 17, 2021, at 12:53 AM, Alexandre Petrescu 
>  wrote:
> 
> Le 15/12/2021 à 19:56, Templin (US), Fred L a écrit :
>> Alex,
>>> A new feature in an ALv2 would be that instead of just a
>>> frag-reassembly from sender to receiver, one would consider
>>> group-degroup of packets too, to reduce overhead.  If this too is
>>> not already there in ALs.
>> The adaptation layer is that layer below the network layer but above
>> the data link layer. The group-degroup functions you are referring to
>> would apply at the adaptation layer send-side entry or receive-side
>> exit.
> 
> Yes, from a topology perspective that's where 'group-degroup' could sit.
> 
> From an ISO layer perspective a 'group-degroup' would probably sit in an
> adaptation layer, below IP and above data link layer.
> 
> A 'group-degroup' function can also be seen in the jumbogram software
> mechanism, rather than in the frag-defrag mechanism.  The jumbogram
> seems to be in the app layer (ApL?) whereas frag-defrag in the
> adaptation layer (AdL?).
> 
> This makes wonder whether a group-degroup function would go into ApL or
> rather in the AdL?

Every function can and may occur at any layer in a layered protocol system. 
Aggregation and coalescing (what you’re calling group/degroup) already exists 
in Ethernet (grouping small packets to avoid the need for padding for min frame 
size artifacts from shared-access MAC mechanisms), TCP (to reduce per-packet 
overhead, often buried inside interface drivers), and applications (HTTP).

The idea that layer implies function or that functions uniquely exist at a 
single layer is one of the great failures of the original OSI model.

The other being that “layer” is ever an absolute, except for the transmission 
layer (i.e., the one where logical bits become physical symbols).

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Luigi Iannone]

> On 16 Dec 2021, at 23:35, Dino Farinacci  wrote:
> 
>> If we don't want to share a common transmission resource, then why do we 
>> need globally unique addresses to use in IP packet headers? Locally unique 
>> addresses would do just as well.
> 
> Just to answer this question specifically. We may not need globally unique 
> addresses. But I need a unique address for anyone I want to talk to and I 
> don't care what transmission networks my packets traverse.
> 
> Therefore, we need unique addresses. However, lets say an address is 24 bits 
> long and we use a random number to generate the address. It is unlikely that 
> there will be an address collision for all the things I want to talk to. So 
> to me I get my unique address. Is it globally unique, well no, but maybe it 
> doesn't have to be. 
> 
> But there will be hosts that want to talk to everyone in the world or at 
> least beyond an address collision domain, so we default for the desire to 
> want/need globally unique addresses. So simply using a random number 
> generator for an IPv6 address may get us there and work sufficiently. 
> 
> Comments?

You touched an important point IMO. We default using globally unique addresses 
and as long as I have one (even temporarily) I use it for all my 
communications. 

May be this is one limitation we should explore how to overcome.

I may want to use a locally unique address to communicate with my local 
devices, where I do not have strong privacy issues because I trust my own 
devices.
I may want to use an address that allows me to access the local CDN cache to 
watch a movie and may be I do not care that much if the CDN identifies me with 
my IP address they already have my credit card number…
I may want a globally unique address so that people can call me to wish me 
merry Xmass ;-) and at the same time I want my privacy so that ISPs do not know 
each and every call I receive …

.. and I want all of the above at the same time..

I guess that my point is that we may want to use multiple different addresses, 
with different properties,  at the same time.
A similar point was made in: 
https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerations-01.txt
 


Ciao

L. (I know I want a lot of things….:-) )
 ___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

[Alexandre Petrescu]

Le 15/12/2021 à 19:56, Templin (US), Fred L a écrit :

Alex,


A new feature in an ALv2 would be that instead of just a
frag-reassembly from sender to receiver, one would consider
group-degroup of packets too, to reduce overhead.  If this too is
not already there in ALs.


The adaptation layer is that layer below the network layer but above
the data link layer. The group-degroup functions you are referring to
would apply at the adaptation layer send-side entry or receive-side
exit.


Yes, from a topology perspective that's where 'group-degroup' could sit.

From an ISO layer perspective a 'group-degroup' would probably sit in an
adaptation layer, below IP and above data link layer.

A 'group-degroup' function can also be seen in the jumbogram software
mechanism, rather than in the frag-defrag mechanism.  The jumbogram
seems to be in the app layer (ApL?) whereas frag-defrag in the
adaptation layer (AdL?).

This makes wonder whether a group-degroup function would go into ApL or
rather in the AdL?

Whether or not the modern QUIC, rather than the older UDP and TCP,
includes a jumbogram mechanism and potentially group-degroup functions
could be explored.  Because IPv6 jumbograms are specified for TCP and
UDP (RFC2675 "jumbograms"), but not for QUIC.  This could further hint
on which layer is best for a group-degroup function, AdL or ApL.

Alex

 Those

sorts of capabilities are already out in the wild in some systems,
but I have not seen a formal IETF spec yet. This seems like something
that could be mentioned in an adaptation layer spec.

Fred


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area