Subject: [rohc] Re: WG last-call for draft-ietf-rohc-tcp-field-behavior-03.txt

From: "West, Mark" <[email-masked]>
Date: Mon, 25 Oct 2004 20:58:09 +0100 (GMT Daylight Time)

Hi Reiner, all,

> Sorry for being late ...

Given the time it's taken me to get around to incorporating these, I think
I'm the one who should be apologising..!

>
> I think this document is ready to go!
>
> Some minor comments:
> --------------------
>
> - Section 3.1.2 discusses IPv4 header fields and this statement caught my attention:
>          "The More Fragments (MF) flag is expected to be zero because
>          fragmentation is generally not expected." Is this a reasonable
> assumption? I have added Matt Mathis to the cc: of this mail, and would
> like to hear from him what he thinks. Since Matt has done a lot of work
> on PMTU discovery, I'm sure that he knows about these things.
>

I've weakened the text -- it seems that 'generally not expected' is a
slightly optimistic view!  Anyway, the point is that this is not, perhaps,
too important: if you have a fragmented packet then there are two
consequences... (i) the fragment containing the TCP header is probably
comparatively large, so if compression is not optimal it's not a big deal;
and (ii) the TCP profile won't be used to compress subsequent fragments
(because there's no TCP header).

Plus, I seem to recall that Matt isn't a great fan of fragmentation -- and
having a compression profile that does not encourage fragmentation seems
to be reasonable!

> - Section 3.1.2, bullet "o Protocol": It seems that the text under this
> bullet is a copy/paste from a previous bullet (IPv6/NextHeader).
> Probably the wording should be different.

Whoops!  Updated...

>
> - Section 4.3:
>    "(1) On the server side, the port number is likely to be a well-known
>       value.  On the client side, the port number is generally selected
>       by the stack automatically.  Whether the port number is replicable
>       depends upon how the stack chooses the port number.  However, most
>       implementations use a simple scheme which sequentially picks the
>       next available port number.  This is clearly exploitable in a
>       compression scheme." If I understand the recent discussions about
> "reset attacks" in the TCPM WG correctly, I'm not sure whether
> implementers should be encouraged to rely on the fact that clients
> simply sequentially pick the next available port number. I suggest
> asking Mark Allman about this one.
>

I guess the jury's still out on the solution to blind reset -- however,
I've changed the text anyway to suggest that relying on / exploiting this
assumption about behavior may be fragile (in that, like the ISS, this
behavior may change)

> - Section 5.2.1:
>   "The Nagle algorithm is an optimisation and not required to be used."
> RFC1122 says that a TCP SHOULD implement Nagle, and as far as I know it
> is turned on by default in all common TCP implementations.
>

Recent personal experience has indeed confirmed that Nagle is turned on by
default!  I've updated the text accordingly...

> - Section 5.3.2 discusses various options and for some options, e.g.,
> POC and T/TCP, and concludes that in practice these options are never
> seen. Why then is it a requirement that "the header compression scheme
> should be able to encode it"?
>

The wording of this (something that Gorry also picked up on) is far too
sloppy.  I've tried to be stricter about the concepts of 'supporting'
[should be able to handle anything] and 'optimised for' [no point in
optimising rare cases].

In this case, there's no requirement for 'optimal' treatment; but it must
be possible to carry all options.

> - Section 5.3.2, last paragraph:
>    "In the discussion above regarding timestamps it is pointed out that
>    there is the possibility (at some time in the future) of negotiations
>    being permitted more generally than in the SYN packets at connection
>    set-up.  Although there seems to be no compelling need to optimise
>    for this, it is worth pointing out that the compression scheme should
>    be able to cope with arbitrary options appearing at any point within
>    the flow." I don't recall any such proposal in the transport area,
> and I don't understand why this last recommendation is made. Again, I
> suggest asking Mark Allman about this one.
>

We kicked this one around a bit, shortly after these comments were
circulated.  I think that our conclusion was that there *had* been some
discussion along these lines, but it was perhaps not appropriate to put
this text in.

The draft now just makes more general statements about not assuming where
options may occur.  Hopefully this is more generic and captures the spirit
of what matters with regard to header compression.  It incidentally
encompasses the idea that timestamps could, conceivably, start/stop
mid-flow.

> I will send a few editing nits directly to the authors.
>
> ///Reiner
>

Cheers,

Mark.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Matt Mathis <[email-masked]>
Date: Mon, 25 Oct 2004 18:49:13 -0400 (EDT)

I think I weighed in on this earlier - I like "fragmentation is generally not
expected" because it is somewhat vague.  Making it less vague requires
explaining all of the caveats.  In the end they all boil down to "our
assumptions hurt the performance of people who are doing things in non-optimal
ways (e.g.  using fragmentation at all with TCP), but without effecting
their interoperation."

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

On Mon, 25 Oct 2004, West, Mark wrote:

> --
> Visit our website at www.roke.co.uk
>
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
>
> The information contained in this e-mail and any attachments is confidential to
> Roke Manor Research Ltd and must not be passed to any third party without
> permission. This communication is for information only and shall not create or
> change any contractual relationship.
>