Hi,
Trying to nudge the discussion on ICMP errors, wanting to nail this down soon...
On Sep 3, 2010, at 1:51 PM, Gerrit Renker wrote:
> a. It would be good to specify how UDP ICMP errors are translated into DCCP
> semantics, in particular the "administratively prohibited" variants of
>
I think you misunderstand.
Gerrit asked if *an existing kernel DCCP* would need to change to work with
UDP encapsulation. That's the question I answered.
DCCP-UDP encapsulation could be implemented at userlevel over a UDP socket
with no kernel changes. Some of its choices, such as the
some
On 10/13/10 10:20 PM, ger...@erg.abdn.ac.uk wrote:
Ok I am out. This is one more specification that alters the behaviour
of another specification. There is no point in all this complexity, it
does not have any practical advantage over implementing congestion
control directly on top of UDP, withou
> This isn't what you're asking, Gerrit, since you are (correctly)
> worrying about UNEXPECTED differences that would only crop up in a
> prototype, but here is a list of expected changes a kernel DCCP would
> require to work with UDP encapsulation.
>
> - Using a 6-tuple instead of a 4-tuple for fl
This isn't what you're asking, Gerrit, since you are (correctly)
worrying about UNEXPECTED differences that would only crop up in a
prototype, but here is a list of expected changes a kernel DCCP would
require to work with UDP encapsulation.
- Using a 6-tuple instead of a 4-tuple for flow iden
On Oct 8, 2010, at 5:39 PM, Phelan, Tom wrote:
>> Section 3.4 speaks only about ECN, but that could be extended to
> clarify
>> that TOS and other IP options are handled as they would be with
> DCCP-STD
>> (right?)
>>
> [TomP] I'm not sure that 4340 has anything to say about the sections of
> TOS
Hi Tom,
thank you for the clarifications. Without wanting to embark on wording details
and/or thought experiments, let me just restate what the comments aimed at.
| > The main point I did not understand is whether the aim is to
| > * encapsulate DCCP as a user-space protocol or
| > * encapsulat
On 10/9/10 4:58 AM, l.w...@surrey.ac.uk wrote:
This is pretty fundamental to Internet transport protocol design.
Agreed. But that doesn't make it automatically correct in all situations.
If the net were still end-to-end, we wouldn't even be talking about this
(well, we might because of badly
On 9 Oct 2010, at 07:37, Andrew Lentvorski wrote:
> On 10/8/10 7:25 AM, Phelan, Tom wrote:
>
>> [TomP] There have been several good comments on this already, but one
>> thing I'd like to add is, how can this work? The problem is that the
>> DCCP checksum includes the IP addresses, which have pot
On 10/8/10 7:25 AM, Phelan, Tom wrote:
[TomP] There have been several good comments on this already, but one
thing I'd like to add is, how can this work? The problem is that the
DCCP checksum includes the IP addresses, which have potentially been
changed along the way.
Ah, the DCCP checksum i
On 10/8/10 1:54 AM, l.w...@surrey.ac.uk wrote:
Andrew,
a few points:
- turning off the UDP checksum (which also acts as a necessary demultiplexing
at-the-right-endpoint check) has repeatedly proven to be a very bad idea.
Subtle NFS corruption etc. See the end-to-end papers. Saying 'well, the
Hi Pasi,
See inline...
Tom P.
> -Original Message-
> From: Pasi Sarolahti [mailto:pasi.sarola...@iki.fi]
> Sent: Thursday, October 07, 2010 5:55 AM
> To: Phelan, Tom
> Cc: Gerrit Renker; dccp@ietf.org
> Subject: Re: [dccp] [udp-encap rev2] discussion/comments
>
>
Fairhurst
> Sent: Friday, October 08, 2010 5:48 AM
> To: dccp@ietf.org
> Subject: Re: [dccp] [udp-encap rev2] discussion/comments
>
> See comments in line...
>
> On 08/10/2010 09:54, l.w...@surrey.ac.uk wrote:
> > Andrew,
> >
> > a few points:
> &g
uk; Phelan, Tom; ger...@erg.abdn.ac.uk;
dccp@ietf.org
> Subject: Re: [dccp] [udp-encap rev2] discussion/comments
>
> Andrew,
>
> a few points:
>
> - turning off the UDP checksum (which also acts as a necessary
> demultiplexing at-the-right-endpoint check) has repeatedly proven to
Hi Andrew,
See inline...
Tom P.
> -Original Message-
> From: Andrew Lentvorski [mailto:bs...@allcaps.org]
> Sent: Friday, October 08, 2010 4:19 AM
> To: Phelan, Tom
> Cc: Gerrit Renker; dccp@ietf.org
> Subject: Re: [dccp] [udp-encap rev2] discussion/comments
>
See comments in line...
On 08/10/2010 09:54, l.w...@surrey.ac.uk wrote:
Andrew,
a few points:
- turning off the UDP checksum (which also acts as a necessary demultiplexing
> at-the-right-endpoint check) has repeatedly proven to be a very bad
idea.
> Subtle NFS corruption etc. See the end-to-
Andrew,
a few points:
- turning off the UDP checksum (which also acts as a necessary demultiplexing
at-the-right-endpoint check) has repeatedly proven to be a very bad idea.
Subtle NFS corruption etc. See the end-to-end papers. Saying 'well, the higher
layers will obviously check their work in
Hi,
On 2010-10-8, at 11:19, Andrew Lentvorski wrote:
> Besides, my (admittedly old) copy of Stevens indicates that UDP
> checksums are optional.
they are optional for IPv4 but (currently) mandatory for IPv6. (Just a data
point.)
Lars
smime.p7s
Description: S/MIME cryptographic signature
On 10/5/10 12:32 PM, Phelan, Tom wrote:
[TomP] I am very against doing the checksum calculation twice, once for
UDP and then again for DCCP. In my opinion, implementations should know
which encapsulation is being used.
I hope I'm missing something, but ...
I'm *very* against usage-context se
Hi,
I'm picking a selection of the Gerrit's comments for discussion below...
I'd appreciate prompt responses, so that we can soon be able to determine if we
have common understanding about the draft, and then move forward.
On Oct 5, 2010, at 10:32 PM, Phelan, Tom wrote:
>> If the latter is the
Hi Gerrit,
See inline...
Tom P.
> -Original Message-
> From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf
Of
> Gerrit Renker
> Sent: Friday, September 03, 2010 6:52 AM
> To: dccp@ietf.org
> Subject: [dccp] [udp-encap rev2] discussion/comments
>
&g
Please find below the transcript of a discussion I sent to Gorry regarding
revision 2 of the udp-encap draft.
As per Gorry's comments, I may have missed parts of the discussion, so please
ignore or correct where I am erring.
The main point I did not understand is whether the aim is to
* encaps
22 matches
Mail list logo
