On Thu, Sep 26, 2024 at 4:39 PM Brian E Carpenter
wrote:
>
> On 27-Sep-24 08:42, Templin (US), Fred L wrote:
> > Hi Brian,
> >
> >> -Original Message-
> >> From: Brian E Carpenter
> >> Sent: Thursday, September 26, 2024 1:22 PM
> >&
t's preso from Netdev 0x15. There's also work by Redhat
and Cilium on the web. I believe this was integrated in Linux 6.3.
https://netdevconf.info/0x15/session.html?BIG-TCP
Tom
> Regards
> Brian
>
> >
> > Thank you - Fred
> >
> >> -Original Messa
On Thu, Sep 26, 2024 at 9:03 AM Tim Chown
wrote:
>
> Hi,
>
>
>
> From: Paul Vixie
> Date: Tuesday, 24 September 2024 at 20:59
> To: Templin (US), Fred L ,
> Internet Area , IPv6 List
> Subject: [Int-area] Re: IP Parcels and Advanced Jumbos (AJs)
>
> Something like this is long needed and will b
ion of
> > middleboxes that try to look at information in transport headers, but they
> > should not look at those information in the first place, or at least do it
> > in a robust way.
> >
> > Best regards,
> >
> > Antoine
> >
> > *From:* Int-ar
On Fri, Mar 22, 2024 at 9:12 AM Robinson, Herbie
wrote:
>
> > Whether something is "legitimate" is a matter of opinion, protocol
> > conformance typically is not.
>
> In the real world, protocol conformance involves how people interpret the
> specs (which have historically been quite loose) and w
ey should not look at those
> information in the first place, or at least do it in a robust way.
>
>
>
> Best regards,
>
>
>
> Antoine
>
>
>
> From: Int-area On Behalf Of Tom Herbert
> Sent: vendredi 22 mars 2024 04:49
> To: Joe Touch
> Cc: Toerles
On Fri, Mar 22, 2024 at 7:45 AM to...@strayalpha.com
wrote:
>
> On Mar 21, 2024, at 10:58 PM, Tom Herbert wrote:
>
>
> Again, I’m not saying it’s not useful. I’m saying it’s just another transport
> - one with particular properties, but still just a transport.
>
>
>
On Thu, Mar 21, 2024 at 9:01 PM to...@strayalpha.com
wrote:
>
> On Mar 21, 2024, at 8:48 PM, Tom Herbert wrote:
>
>
>
>
> On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com
> wrote:
>>
>>
>>
>>
>>> You’ve just described a transpor
On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com
wrote:
>
>
>
> You’ve just described a transport protocol that the intermediate nodes
>> know.
>>
>
> Joe,
>
> A transport protocol doesn't meet the requirements. They don't work with
> any transport protocol other than themselves,
>
>
> They do
On Thu, Mar 21, 2024, 7:28 PM to...@strayalpha.com
wrote:
>
> > On Mar 21, 2024, at 7:18 PM, Tom Herbert wrote:
> >
> > On Thu, Mar 21, 2024 at 6:52 PM to...@strayalpha.com
> > wrote:
> >>
> >> On Mar 21, 2024, at 6:36 PM, Tom Herbert wrote:
&
On Thu, Mar 21, 2024 at 6:52 PM to...@strayalpha.com
wrote:
>
> On Mar 21, 2024, at 6:36 PM, Tom Herbert wrote:
> >
> > On Thu, Mar 21, 2024 at 5:38 PM to...@strayalpha.com
> > wrote:
> >>
> >> On Mar 21, 2024, at 8:01 AM, Tom Herbert wrote:
> >&
On Thu, Mar 21, 2024 at 5:38 PM to...@strayalpha.com
wrote:
>
> On Mar 21, 2024, at 8:01 AM, Tom Herbert wrote:
>
> I haven’t seen it mentioned yet (apologies if so), but there is a big
> difference between extension headers and encapsulated protocols.
>
> Extension headers
On Thu, Mar 21, 2024 at 2:36 PM Brian E Carpenter
wrote:
>
> On 22-Mar-24 09:04, Tom Herbert wrote:
> > On Thu, Mar 21, 2024 at 12:46 PM Templin (US), Fred L
> > wrote:
> >>
> >> Brian,
> >>
> >>> Why should the IETF spend effort on upgrad
--
> > -----------
On Thu, Mar 21, 2024 at 11:16 AM Robinson, Herbie
wrote:
>
> It may not break the formal definition of any protocol, but it breaks common
> usage patterns in a way that will prevent most sites from using it.
Herbie,
Maybe. But I think it's ironic that the same argument is used to keep
on IPv4 i
On Thu, Mar 21, 2024 at 9:54 AM Robinson, Herbie
wrote:
>
> Not including the port numbers in the hash is insufficient. You end up with
> all the traffic on one or two cores. What you are saying is this proposal
> will effectively break all unmodified NICs.
Herbie,
Again, this proposal doesn
On Thu, Mar 21, 2024 at 9:11 AM Robinson, Herbie
wrote:
>
> It’s definitely a problem for the 10G x7-- NICs that Intel is currently
> selling (I’ve been working on porting the driver). It would require
> coordinated firmware and driver updates because the driver to firmware
> interface isn’t d
ogies. Do not click links or open attachments unless you recognize
> > the sender and know the content is safe.]
> >
> >
> >
> >
> >
> > On Mar 20, 2024, at 9:35 PM, Toerless Eckert wrote:
> >
> >
> >
>
> On Mar 20, 2024, at 9:35 PM, Toerless Eckert wrote:
>
>
>
> On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote:
>
> In other words, Destination Option Headers do not have fundamentally distinct
> processing requirements on the destination h
On Thu, Mar 21, 2024 at 7:46 AM to...@strayalpha.com
wrote:
>
> On Mar 20, 2024, at 9:35 PM, Toerless Eckert wrote:
>
>
> On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote:
>
> In other words, Destination Option Headers do not have fundamentally distinct
> pr
On Thu, Mar 21, 2024 at 12:36 AM Bob Hinden wrote:
>
> Tom,
>
> > On Mar 21, 2024, at 2:20 PM, Tom Herbert
> > wrote:
> >
> > On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert wrote:
> >>
> >> Btw: When i asked on of the 6MAN chairs, about th
On Wed, Mar 20, 2024 at 9:35 PM Toerless Eckert wrote:
>
> On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote:
> > > In other words, Destination Option Headers do not have fundamentally
> > > distinct
> > > processing requirements on the desti
gistry is. In any case, for IPv4 extension headers it makes sense to
be consistent with IPv6.
Tom
>
> Cheers
> Toerless
>
> On Tue, Mar 05, 2024 at 05:56:54PM +0100, Toerless Eckert wrote:
> > On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote:
> > > We c
On Tue, Mar 5, 2024 at 8:56 AM Toerless Eckert wrote:
>
> On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote:
> > We can treat them as EH for purposes of extension header ordering in
> > section 2.2. Also, IPv4 AH needs to be updated to take EH into account
> > a
H. The draft will need to update RFC4302 to
describe AH processing with IPv4 EH present.
RFC4303 needs an update as well, but that's just to say that EH after
the ESP is covered by the encryption, but I don't believe that
materially changes the requirements.
Tom
>
> Cheers
>
ssage -
From:
Date: Thu, Feb 22, 2024 at 5:29 PM
Subject: New Version Notification for draft-herbert-ipv4-eh-03.txt
To: Tom Herbert
A new version of Internet-Draft draft-herbert-ipv4-eh-03.txt has been
successfully submitted by Tom Herbert and posted to the
IETF repository.
Name: draft-he
f Of *Paul Vixie
> *Sent:* Monday, December 18, 2023 8:12 PM
> *To:* Tom Herbert ; Christian
> Huitema
> *Cc:* Gorry (erg) ; int-area
> *Subject:* [EXTERNAL] Re: [Int-area] Jumbo frame side meeting at IETF118
> - notes
>
>
>
> *[**EXTERNAL SENDER**: This email originate
On Mon, Dec 18, 2023 at 11:24 AM Christian Huitema wrote:
>
> On 12/18/2023 9:15 AM, Kyle Rose wrote:
> > Right, I should have said*at best* a 6x improvement. The point I'm trying
> > to get to is: how much sense does it make to try to make the public
> > internet safe for jumbo frames? I honestl
On Mon, Dec 18, 2023 at 8:38 AM Kyle Rose
wrote:
>
> Apologies for not being able to make the meeting. Had I been able to attend,
> the question I was going to ask was: with respect to overhead, there's a
> constant factor 6x improvement when moving from 1500->9000 octets. How
> quickly do hard
On Mon, Dec 18, 2023 at 8:15 AM Tim Chown
wrote:
>
> Hi,
>
> Apologies for the delay in posting these notes. Gorry and I held a side
> meeting in Prague on the topic of (lack of) use of jumbo frames, and what
> topics might lie within the IETF’s remit to help promote greater use.
>
> After talki
-
From:
Date: Fri, Dec 15, 2023 at 4:55 PM
Subject: New Version Notification for draft-herbert-ipv4-eh-02.txt
To: Tom Herbert
A new version of Internet-Draft draft-herbert-ipv4-eh-02.txt has been
successfully submitted by Tom Herbert and posted to the
IETF repository.
Name: draft
le, someone, somewhere will inevitably see that some operation
assurance fails-- when that happens it cannot lead to detrimental
behaviors. If you can account for all possible behaviors and show that
there are no detrimental behaviors in the edge condition, then the
protocol might be considered robu
On Mon, Nov 27, 2023 at 9:24 AM Templin (US), Fred L
wrote:
>
> Hi Tom,
>
> > -Original Message-----
> > From: Tom Herbert
> > Sent: Monday, November 27, 2023 9:00 AM
> > To: Templin (US), Fred L
> > Cc: int-area
> > Subject: Re: "
On Mon, Nov 27, 2023 at 8:01 AM Templin (US), Fred L
wrote:
>
> Hi Tom,
>
> > -Original Message-----
> > From: Tom Herbert
> > Sent: Friday, November 24, 2023 11:33 AM
> > To: Templin (US), Fred L
> > Cc: int-area
> > Subject: Re: "
t Header). This would also ensure that the
packet isn't misinterpreted at the receiving host if for some reason
it doesn't process the fragment option.
Tom
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> From: Int-area on behalf of Tom Herbert
>
> Date: F
or
references to IP Parcels or OMNI as they don't seem essential to the
goal of a larger fragment identifier.
Tom
>
>
>
> Thank you – Fred
>
>
>
>
>
> From: Templin (US), Fred L
> Sent: Tuesday, November 21, 2023 7:14 PM
> To: Tom Herbert ; Templin (US), Fre
high. If the data needs to be read or
modified by routers then Hop-by-Hop Options is appropriate, if it's only
read at the end host or intermediate nodes then Destination Options should
be used.
Tom
>
> Fred
>
>
>
> *From:* Int-area *On Behalf Of *Templin (US),
> Fred L
nuity in 8-octet alignment.
> Especially since no implementations currently exist.
>
4 bytes is 0.3% of minimum 1280 bytes MTU. I don't believe that is
significant enough savings to diverge from the long established
requirements of the standard.
Tom
>
>
> Fred
>
>
>
>
On Tue, Nov 21, 2023, 11:44 AM Templin (US), Fred L wrote:
> Section 8 of "Identification Extension for the Internet Protocol" proposes
> a new IPv6 extension
> header called the "Extended Fragment Header" that includes a 96-bit (12
> octet) Identification
> field making the total length of the e
ter.
Tom
>
> Thank you - Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 12:55 PM
> > To: Templin (US), Fred L
> > Cc: Templin (US), Fred L ; Joel Halpern
> > ; int-area
> > Subject: Re: [I
hat level, mis-delivery is possible and so probably better to
> detect it as early as possible.
>
> Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 12:00 PM
> > To: Templin (US), Fred L
> > Cc: Templin (US)
rity check needs to go
> somewhere and IPv6
> does not include a checksum field in the IPv6 header.
>
> Thank you - Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 11:02 AM
> > To: Templin (US), Fred L
> >
s is a type of new checksum of L4 checksum, not the TCP/UDP
checksum defined in RFC793/RFC768? Do you really need this checksum to
cover the transport layer header, could it just be over pseudo header?
(that would greatly simplify router operations)
Tom
>
> Fred
>
> > -----Original
flight.
Tom
>
>
>
>
>
> Thanks - Fred
>
>
>
> From: Int-area On Behalf Of Templin (US), Fred L
> Sent: Tuesday, November 14, 2023 7:28 AM
> To: Tom Herbert
> Cc: Joel Halpern ; int-area
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service mode
E. IETF is not free to
> > >> redefine that.
> > >>
> > >> 2) There are approaches for links with long delays (sometimes even
> > >> longer than the 8 minutes to which you refer). If you want to propose
> > >> different mechanisms, have t
On Mon, Nov 13, 2023, 4:41 PM Templin (US), Fred L <
fred.l.temp...@boeing.com> wrote:
> Hi Tom,
>
> On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L
> wrote:
> >
> > Hi Tom, see below for responses:
> >
> > > -Original Message-
&
On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L
wrote:
>
> Hi Tom, see below for responses:
>
> > -Original Message-
> > From: Int-area On Behalf Of Tom Herbert
> > Sent: Monday, November 13, 2023 12:39 PM
> > To: Templin (US), Fred L
>
nge over the course of a connection).
The problem with HBH extension headers is that they experience a high
drop rate on the Internet. The draft discussed some mitigations and
there is work in 6man to address this.
Tom
>
>
> Thank you.
>
> Linda
>
> -Original Message-
implementation considerations.
Added a request for an IANA registry for Ticket Types.
Any comments are welcome!
Tom
-- Forwarded message -
From:
Date: Sat, Oct 7, 2023 at 1:55 PM
Subject: New Version Notification for draft-herbert-fast-07.txt
To: Tom Herbert
A new version
define a key distribution protocol if signals
are encrypted
Any feedback is appreciated!
Thanks,
Tom
-- Forwarded message -
From:
Date: Wed, Oct 4, 2023 at 7:01 AM
Subject: New Version Notification for draft-herbert-host2netsig-00.txt
To: Tom Herbert
A new version of Internet
Hi Dan,
Thanks for the comments.
On Tue, Oct 3, 2023 at 3:46 PM Dan Wing wrote:
>
> On Sep 29, 2023, at 9:36 AM, Tom Herbert
> wrote:
>
>
> On Fri, Sep 29, 2023 at 8:49 AM Robinson, Herbie
> wrote:
>
>
> OK, I see where you are coming from and it makes sense.
p Options Header (described
draft-herbert-eh-inflight-removal)
>
> Thanks for putting the requirements together.
Thanks for the feedback!
Tom
> Cheers,
> Kiran
>
>
>
> On September 27, 2023 at 4:11:39 PM, Tom Herbert
> (tom=40herbertland@dmarc.ietf.org
> (mailto:to
h performance datapath?
Tom
>
> From: Int-area On Behalf Of Tom Herbert
> Sent: Friday, September 29, 2023 11:12 AM
> To: Robinson, Herbie
> Cc: Tom Herbert ; int-area
> ; tsvwg
> Subject: Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for
> draft-herbert
On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie
wrote:
>
> I have a couple of observations
>
Hi Herbie,
Thanks for the comments!
> There is a desire to make host to network signals processable in fast router
> paths without variable length packet processing. Yet at the same time, there
> is
anks,
> Tom
>
> -- Forwarded message -
> From:
> Date: Wed, Sep 27, 2023 at 4:09 PM
> Subject: New Version Notification for draft-herbert-net2hostsig-00.txt
> To: Tom Herbert
>
>
> A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been
&
s, that's a typo. Thanks for putting it out.
Tom
>
> BR，
> Rachel
>
> > -邮件原件-
> > 发件人: tsvwg 代表 Tom Herbert
> > 发送时间: 2023年9月28日 7:11
> > 收件人: int-area ; tsvwg
> > 抄送: Michael Richardson
> > 主题: [tsvwg] Fwd: New Version Notification fo
ft-herbert-net2hostsig-00.txt
To: Tom Herbert
A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been
successfully submitted by Tom Herbert and posted to the
IETF repository.
Name: draft-herbert-net2hostsig
Revision: 00
Title:Host to Network Signaling
Date: 2023-0
ve thought many times about adopting IPv6 extension headers in
> IPv4 packets and have proposed it several times with no uptake. An IPv4
> option seems like a cleaner uptake for the IPv4 architecture.
It's likely a case where real world considerations trump aspirations
of architectural purit
ragment Header defined in RFC8200
in IPv4. This is discussed in section 2.1.2 of draft-herbert-ipv4-eh.
Tom
>
> Fred
>
> > -Original Message-
> > From: Templin (US), Fred L
> > Sent: Friday, September 01, 2023 8:11 AM
> > To: 'Tom Herbert' ; Tem
On Thu, Aug 31, 2023 at 2:53 PM Templin (US), Fred L
wrote:
>
> -Original Message-
> From: I-D-Announce On Behalf Of
> internet-dra...@ietf.org
> Sent: Thursday, August 31, 2023 2:52 PM
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-templin-intarea-ipid-ext-04.txt
>
> Internet-
aving a few bytes of overhead probably isn't enough.
In other words, you'll really need to do your homework on what people
have over the years done to address the performance problems IP
Parcels endeavours to solve if the community is going to accept IP
Parcels :-).
Tom
>
> Fred
>
On Wed, Nov 9, 2022 at 7:47 AM Templin (US), Fred L
wrote:
>
> Richard, thank you for your message. The intarea community must understand
> that
>
> the live IP Parcels presentation given today was only a “roadmap” to a proper
>
> presentation which could not be given due to time constraints. The
On Mon, Aug 1, 2022 at 9:51 AM Templin (US), Fred L <
fred.l.temp...@boeing.com> wrote:
> Juan Carlos and intarea, there is actually much more to be said about this
> from a “big-picture”
>
> standpoint that has not been said yet. In particular, the AERO/OMNI and IP
> Parcels architecture
>
> uniq
hat the
source host put into the packet sent on the network? Is it the destination
host, or the address of some intermediate node that will perform reassembly
and then forward the reassembled packet to the destination via some sort of
routing header or encapsulation?
Tom
>
> Fred
>
>
&g
pped-- I think that's
going to be a hard sell in itself. However, this problem only occurs if an
intermediate performs reassembly, so if only the end host can reassemble
then there's no issue. Segments with a good packet checksum are accepted,
those with bad ones are dropped and checksums
sion but still in a single pass. You spoke before of NICs adapting
> to support
>
> TCP jumbograms – if they can do that, why not a very straightforward
> application
>
> of Internet checksum? I haven’t looked at this in a long while, but isn’t
> this also
>
> similar to
ation to try
> to pass the
>
> largest possible parcels on to the next hop instead of passing many
> smaller ones. It is
>
> really just a concatenation of segments of sub-parcels belonging to the
> same original
>
> parcel. Reordering is unimportant – it is OK to conc
On Tue, Jul 12, 2022 at 7:31 AM Robinson, Herbie <
herbie.robin...@stratus.com> wrote:
> Fred Templin Wrote:
>
> > Tom:
>
> >>The algorithm isn't the problem, it's supporting new protocols and
> multiple
>
> >>checksums in a packet in hardware.
>
>
>
> >But Tom, how hard can this be? Instead of ru
the
>
> largest possible parcels on to the next hop instead of passing many
> smaller ones. It is
>
> really just a concatenation of segments of sub-parcels belonging to the
> same original
>
> parcel. Reordering is unimportant – it is OK to concatenate sub-par
That means
a device performing reassembly has to receive one packet, hold it, and wait
for the following packet to perform reassembly. That makes reassembly,
unlike fragmentation, a non-work conserving process. Many issues and
policies arise from this. For instance, what happens if a packet is he
On Mon, Jul 11, 2022 at 12:22 PM Templin (US), Fred L <
fred.l.temp...@boeing.com> wrote:
> Richard and others, thank you for these comments and for the ensuing
> discussion that
>
> took place over the time I was away on vacation. Strange how the timing
> hit when I
>
> was away from the office a
to represent these jumbo packets that
might be created locally on receive (as opposed to using some npn-standard
custom OS API).
Tom
> Thanks
>
> Gyan
>
> On Sun, Jul 3, 2022 at 2:52 PM Tom Herbert wrote:
>
>>
>>
>> On Sat, Jul 2, 2022, 9:26 PM Gyan Mishra
’s going to
>> be further discussion on this, I’d want to see more explanation of who
>> would intend to support and deploy this solution to the problem.
>> >
>> > If this is a matter of sending fewer packets over a particular link of
>> the network, the use of a
At this point, I don't see IP parcels as being a significant benefit to
host performance which, as I understand it, is the primary motivation.
While it's an interesting idea, I don't support adoption.
A recent patch to the Linux kernel allows for GSO/GRO segments greater than
64K, using RFC2675 Ju
1TB Ethernet?) that will be rolled out as new hardware.
> >>>
> >>> I want to put a gold star next to the above. AFAICT, pushing the MTU
> and
> >>> implementing IP parcels can get us to 1TB Ethernet practically
> overnight.
> >>> Back in the 1980's,
On Thu, Mar 24, 2022 at 7:27 AM Templin (US), Fred L
wrote:
>
> Tom - see below:
>
> > -Original Message-----
> > From: Tom Herbert [mailto:t...@herbertland.com]
> > Sent: Thursday, March 24, 2022 6:22 AM
> > To: Templin (US), Fred L
> > Cc: Eggert,
>
> checking that they were sent by a peer that was earnestly doing GSO. These
> aspects
>
> would make it very difficult to work GSO/GRO into an IETF standard, plus it
> doesn’t
>
> work for IPv6 at all where there is no IP ID included by default. IP Parcels
> address
On Wed, Mar 23, 2022, 9:54 AM Templin (US), Fred L <
fred.l.temp...@boeing.com> wrote:
> Hi Tom,
>
> > -Original Message-----
> > From: Tom Herbert [mailto:t...@herbertland.com]
> > Sent: Wednesday, March 23, 2022 6:19 AM
> > To: Templin (US), Fred L
>
On Tue, Mar 22, 2022 at 10:38 AM Templin (US), Fred L
wrote:
>
> Tom, see below:
>
> > -Original Message-----
> > From: Tom Herbert [mailto:t...@herbertland.com]
> > Sent: Tuesday, March 22, 2022 10:00 AM
> > To: Templin (US), Fred L
> > Cc: Eggert, L
On Tue, Mar 22, 2022 at 10:40 AM Robinson, Herbie
wrote:
>
> > The nice thing about TSO/GSO/GRO is that they don't require any
> > changes to the protocol as just implementation techniques, also
> > they're one sided opitmizations meaning for instance that TSO can be
> > used at the sender without
On Tue, Mar 22, 2022 at 7:42 AM Templin (US), Fred L
wrote:
>
> Lars, I did a poor job of answering your question. One of the most important
> aspects of
>
> IP Parcels in relation to TSO and GSO/GRO is that transports get to use a
> full 4MB buffer
>
> instead of the 64KB limit in current pract
On Thu, Jan 27, 2022 at 3:43 PM to...@strayalpha.com
wrote:
>
> Hi, Tom,
>
> > On Jan 27, 2022, at 2:46 PM, Tom Herbert wrote:
> >
> > On Thu, Jan 27, 2022 at 2:17 PM to...@strayalpha.com
> > wrote:
> >>
> >> FWIW, GRO/GSO give no end of heada
On Thu, Jan 27, 2022 at 2:17 PM to...@strayalpha.com
wrote:
>
> FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp.
> the current ones to extend option space after the SYN
> (draft-ietf-tcpm-tcp-edo).
GRO and GSO are software implementations and in most deployments
>
> A
On Tue, Jan 25, 2022 at 11:30 AM Geoff Huston wrote:
>
>
>
> > On 26 Jan 2022, at 5:17 am, Tom Herbert wrote:
> >
> > On Tue, Jan 25, 2022 at 3:38 AM Geoff Huston wrote:
> >>
> >>
> >>
> >>> On 25 Jan 2022, at 6:19 pm, Dirk
On Tue, Jan 25, 2022 at 3:38 AM Geoff Huston wrote:
>
>
>
> > On 25 Jan 2022, at 6:19 pm, Dirk Trossen
> > wrote:
> >
> > All,
> >
> > Thanks for the great discussion, following our side meeting at IETF 112, so
> > far.
> >
> > I wanted to turn the discussion to a key question which not only ar
nel endpoint it's decapsulated and the
originally sent packet is delivered to the user. ID/locator split in IPv6
addresses is just an alternative for doing this compared to using a more
expensive encapsulation like GRE or VXLAN and similarly would not be
exposed to the Internet.
Tom
>
>
;s
concerns about it. It pains me to say that because the whole point of a 128
bit address space in IPv6 was to eliminate the NAT abomination :-)
Tom
>
>
> Happy new year!
>
> Thanks,
>
> Yihao
>
>
>
> *From:* Tom Herbert
> *Sent:* 2021年12月31日 2:30
> *To:*
On Mon, Dec 27, 2021 at 7:00 PM Abraham Y. Chen wrote:
> Hi, YiHao:
>
> 0)Hope you had a Merry Christmas as well!
>
> 1)Re: Ur. Pts 1) & 2):Allow me to modify and expand your
> definitions of the abbreviations, ICP & ISP, a bit to streamline our
> discussion, then focusing on related
't have many paths like that yet, but parcels might provide
> motivation for trending in that direction.
>
> I was originally thinking I would capture all this in the OMNI spec instead
> of the
> IP parcels spec, but I see that a lot of this should probably also go in IP
>
P parcel can be lost without
losing the whole parcel? Is the idea that parcels can make up a >64K
super packet? What if a segment in a parcel is greater than an MTU in
the path, is an intermediate node breaking up a parcel expected to
fragment the segment, or send a PTB?
Tom
>
> Thanks
stack, I think it's much better for
the network to just focus or forward packets without delay and let the host
handle the details of receive processing, reassembly, security, etc.
Tom
>
> Fred
>
>
>
> *From:* Tom Herbert [mailto:t...@herbertland.com]
> *Sent:* Monday, Decem
cenario, the network will take a detrimental action such
as forcibly breaking a connection (e.g. this is what can happen when a NAT
evicts a TCP connection because it has run out of memory). IMO, maintaining
state in the network is a bad, albeit unfortunately prevalent, idea.
Tom
>
>
On Mon, Dec 20, 2021 at 1:27 AM Jiayihao wrote:
>
> Hello Tom,
>
>
>
> The privacy countermeasure for IPv4/IPv6 is interestingly different.
>
> IPv4 usually utilize CGNAT, i.e., M(hosts)-to-N(IPs), where M >> N so that
> the host could remain anonymous
>
> IPv6 usually utilize Temporary address,
>
>
> The world is not just TCP anymore. QUIC and other UDP-based transports
> have already
>
> shown performance increases using facilities like GSO/GRO which are
> essentially a short
>
> term and non-standard implementation of what parcels promise to do in the
> long term.
>
Fred,
Can you expl
On Fri, Dec 17, 2021 at 7:16 PM Dino Farinacci wrote:
>
> > 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
> > C
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 rand
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 clie
On Mon, Dec 6, 2021 at 6:17 PM Dino Farinacci wrote:
>
> > Dino,
>
> Hey Tom. I should make it clear that I am replying to email in the context of
> "user requirements", that means end user requirements. Hence my comment about
> 1400.
>
> > Definitely at least for a limited domain. For instance,
On Mon, Dec 6, 2021 at 1:52 PM Dino Farinacci wrote:
>
> Last email was the main point I wants to get across. Now to answer your
> questions inline.
>
> > On Dec 6, 2021, at 4:28 AM, Luigi Iannone wrote:
> >
> > Having said that, this is not caused by addressing itself, right?
>
> Right, IMHO.
>
On Fri, Dec 3, 2021 at 3:19 AM Alexandre Petrescu
wrote:
>
> - make sure the Internet does no harm.
>
> - use shorter paths and not artificially-long paths like with VPN
>gateways, video session rdv points. Use more direct communications
>
> - accommodate more bandwidth: 10petabit/s for a lin
1 - 100 of 411 matches
Mail list logo
