Subject: [rohc] TCP compression

From: "West, Mark" <[email-masked]>
Date: Sun, 7 Sep 2003 22:41:23 +0100 (GMT Daylight Time)

Hi all,

Whilst thinking about the TCP profile, I got to wondering about one of the
tougher problems that we seem to face: what MSS do we assume?

With efforts like the pmtud wg looking to push the path-MTU up, what
should we go for?  Now, it is clear that the kind of links that have
really big MTUs are less likely to be an important target for header
compression (isn't it?!)

I should also be clear that we are categorically *not* talking about TCP
compression only working for a limited set of MSS's -- we are simply
talking about the 'sweet spot' for which it will be optimised.

So, I don't see a need to look (much) above the Ethernet MTU..?  (As a
baseline)

The other issue that occurs is that of retransmissions (which will cause
jumps in sequence and ack number).  However, intuition and a bit of
playing with the TFRC equations leads me to suggest that this isn't such a
big deal:

- if the link has a low loss-rate, then the probability of retransmission
is correspondingly low and so we don't need to support this with highly
optimised packet formats (since it is so rare); but

- if the link has a high loss-rate, then the probability of retransmission
is that much greater, but the window will be correspondingly constrained,
reducing the range of sequence-space over which we need to be able to
range.

So, we should support limited sequence-/ack-number jumps relatively
efficiently and be less worried about larger jumps...

Any thoughts..?

Mark.

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

---

From: "West, Mark" <[email-masked]>
Date: Thu, 11 Sep 2003 21:51:26 +0000 (GMT)

Hi Gorry,

Thanks for your comments -- follow-up inline...

Cheers,

Mark.

> West, Mark wrote:
> Aha.

;-)

> Maybe so. It's actually not QUITE the same, since what matters when
> determining ROHC
> benefit is the PROPORTION of traffic (volume/packets depending on the
> bottleneck),
> rather than the size of the largest packet.
>

Hmmm... ok, so if the packet size is driven more by the application than
simply limited by the path-MTU, then an increase in path-MTU may be less
of an issue.

This tends to suggest that I was simply imprecise in my wording: flows
that *use* really big MTUs are less likely to be an important target...

... (flows that *don't* use big MTUs look [generally!] like flows with
small MTUs ;-)

> Will you also be considering routing asymmetry - where you may have a
> small PMTU specified
> in the ACK direction and a large (potentially very large PMTU on the
> DATA direction)?
>

Another lack of clarity / completeness in my mail (obviously having a bad
day!)

I hadn't separated them, to be honest...  so, no, I hadn't explicitly
considered routing asymmetry.  However, the data direction is more easily
manageable (I think) than the ack direction.  So, if we are always talking
about large MTU on the data path, then I'm less worried.

> What are the implications of getting this wrong?

Lack of efficiency.  That's it (I think).

If you were to deploy ROHC-TCP, you would be able to select the robustness
level at the compressor (the number of dropped packets that you can
tolerate).  The compressed packets will be based on *some* assumptions of
MTU and robustness level (I don't see a way around that).  If you have a
combination that is considerably outside of the design choice, then
packets will not compress as efficiently.  Your choice would then be to
live with the inefficiency or to reduce the robustness.  The latter is
unlikely to be a practical choice, however.

It may well be that the right thing to do is to make sure that the impact
on efficiency is as low as it is practicable to achieve...  (I have a
suspicion that this is an easy point to agree, although the definition of
'practicable to achieve' may need more though..?!)

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 Sep 2003 17:12:47 +0100

Aha.