Subject: [rohc] Re: ROHC WGLC (Questions): draft-ietf-rohc-tcp-field-behavior-03.txt

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

Hi Gorry,

> I enclose the part of my review contains substantive questions. I have tried
> to separate editorial and requests for clarification of text into a separate
> list.

Thanks again for this review.  Some comments on the -04 updates, inline.
Hopefully they'll make sense, but I'm sure that you'll shout if I've
missed anything..!

Cheers,

Mark.

> *: Page 4: Intro, para 6:
> "It is unclear how reserved bits should be handled.."
> - I agree there are various options for handling reserved bits, but the text
> in this paragraph is weak. IMHO, we MUST expect that these bits may be used
> in future revisions of the protocol and it is important that these are
> transparently supported - but it is not possible to optimise for cases that
> have yet to be defined.
>

Fair point -- I've updated the text.

> *: Page 5: Section 2:
> - What is the intended type of document?
> - I'd assumed INFO RFC, in which case this terminology is not needed (and
> seems not to be used).
> - RFC 2119 could also then be removed from the references if this section is
> removed (see later note).
>

I also assume INFO.

> *: Page 8: STATIC-KNOWN
> "Fragmentation should not be common"
> (i) This seems OK, but is it the case that fragmentation is still sometimes
> observed in "broken" tunneled architectures (e.g. those that do not handle
> PMTUD and/or do not observe the expected rules)? - Thoughts?
> (ii) Could you include an RFC reference to PMTUD?
> (iii) "should not be common due to" -> "is not expected to be a common in
> the Internet"
> (iv) The final sentence is not clear to me - can you add text to explain
> this?
>

Fragmentation was also one of Reiner's points.  I haven't included a link
to the current PMTUD work.  However, I have generally overhauled this
text.

> *: Page 8: Protocol
> "This field will usually have the same value in all packets"
> - Tunnels and Protocol values:
> (i) I thought this was implied in the definition of a "Packet Flow", but
> perhaps this is considering the case of tunnels or security extensions?
> (ii) Do you assume the set of tunnel encapsulations are always the same for
> the lifetime of a single flow? - I was thinking of (e.g.) the use of tunnels
> within mobile IP. What would be the implications of additional/removal of
> tunnels on the ROHC behaviour?
>

> *: Page 8: Flags
> "It appears unwise to.."
> - Can the WG decide whether it is undesirable or acceptable, and update the
> text to remove the ambiguity?

Oh, it's definitely unwise!  Ambiguity removed...

>
> *: Page 8: Flags
> "The alternative coding of CHANGING is suggested..."
> - The current text (*suggested*) seems very loose: Is this possible?
> - Is it the recommended approach?
>

It's recommended -- strengthened the text.

> *: Page 9: final para
> "It is expected tha*n* some additional checksum (such as CRC)..."
> - This seems very desirable: I'm surprised that this is not a requirement?
>

This isn't a requirements' document -- we've got one of them, and I
believe that this *is* a requirement.  However, I've strengthened the text
for the additional checksum.

> ***: Page 12: Section 4.1
> - The document says the DF field is not seen as replicable between flows
> - This seems acceptable, but why is it NOT possible to replicate this (can
> you explain - I don't understand)?
>

Having reviewed this, I don't understand why it's not *possible* to
replicate the field (and have changed the text accordingly).  However, the
idea of signalling replication (or not) of a 1-bit field is a bit, well,
daft.  I've added text to this end...

> ***: Page 13: Point (1) - DSCP remarking
> (i) I think the same "type of traffic" does not mean the same as "traffic
> with the same DSCP value" - i.e. traffic with the same diffserv class.
> Similar "traffic" could be assigned different DSCP values based on
> destination, congestion state, other policies.
>
> (ii) I'm not clear on the documents guidance here. My understanding was that
> DS traffic conditioners could be expected to modify a flow's DSCP value
> based on metered flow properties and overall traffic levels. This being so,
> then surely the DSCP value may be reasonably expected to change (i.e. be
> remarked) between a small number of DSCP values. Passing through multiple
> diffserv domains may result in multiple remarkings. There are likely to be
> commonalities between the set of DSCPs encountered by different flows
> (packet streams) between a pair of end hosts. RFC2475 says:
>

Yes, remarking could happen.  But header compression is done on a
point-to-point link, so I'm not sure that we expect too much variability
from the different domains.

However, I've tried to clarify the text.

>
> *: Page 17: IP TOS in table
> (i) Would it be better to call this DSCP?
> (ii) The remarking discussion above raises the question about whether this
> is RC or Alternating. - Thoughts?
>

Having considered this, 'alternating' seems a better choice than
rarely-changing.  So I've changed it accordingly (it doesn't significantly
affect things), as it feels more reasonable.  From a profile design
perspective, it's likely to be handled the same way regardless of whether
the field is RC or alternating.

> ***: Page 22: Section 5.2.1
> - The MSS agrees an upper bound, but the actual used value may be different.
> The use of PMTUD suggests that actual segment size used may be less than the
> segment size that was originally negotiated.  Specifically if the segment
> size is less than the negotiated MSS, it may be expected that PMTUD
> algorithm will probe using a range of segment sizes as a session progresses.
> - THOUGHTS & IMPLICATIONS (if any)?

Good point -- I've included a reference to PMTU.  My 'thought' is that you
are right about this.  The 'implications', however, are negligible (if
any).  All we are really thinking about here is the ability to make use of
a stable payload size to improve compression.  Changes of segment size in
active PMTU probing would disrupt this.

>
> ***: Page 33: Section 5.3.2: final para
> - I'd like to see some discussion on what happens when new options do
> appear, and what needs to be done!
> - Clearly these can not be optimised for...
> - Will packets with the new option be discarded (surely not)?
> I'd expect these to be transparently forwarded (is there any guidance?)
>

Any option will always be carried transparently.  As you suggest, the only
issue is whether or not the conveyance of the option can be optimised.
I've added guidance to this end...

> *: Page 34: Section 6.3: final para
> "will support experimental options"
> - Does this mean will be optimised for?
> - Does this mean the packet will be discarded (surely not)?
> The word support needs clarification, I'd expect these to be transparently
> forwarded.
>

Reiner also picked up on this -- I've tried to be much stricter about the
'supported' and 'optimised for'.

One note that I haven't made in the draft, but is a more general comment
on the philosophy of header compression: we *never* discard a packet.
Worst case is to send the packet as 'uncompressed'.

> *: Page 35: Section 6.6: final para
> "support for reordering of compressed packets will require"
> - Explain where you are referring to: "reordering on the path between the
> compressor and decompressor"

There is now an excellent draft discussing the support of re-ordering in
ROHC profiles.  Given this, I've removed this text -- it's superceded by
the later work.

>
> ***: References
> - Normative references are always debatable, and I'd like to open this
> debate at this stage.
> - I'd have definitely expected that TCP standards that this analysis relies
> on MUST be normative references. The justification is that these references
> *DEFINE* the behaviour that is described, if they are modified by subsequent
> RFCs then the conclusions could change - I thought that was what we had
> normative references for?
>

I really wasn't sure about the normative/informative split -- so sincere
thanks for the steer!  Your suggestion makes sense -- I've taken your
split below as a starting point.

> - I propose the following are normative to this document:
> 1,2,3,4,7,8,9,11,12,16,17,18,24,25,26,27,31,33,38.
>
> - I suggest the other references provide background, explanation of use, or
> examples of mechanisms that require/utilise specific headers.
>
> - Reference 23 is normative if used, but is an appropriate to this RFC and
> should be removed.
>

Deleted.

> - Reference 39 includes a typo - remove ".txt".
>

Whoops!

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

---

From: gorry fairhurst <[email-masked]>
Date: Tue, 26 Oct 2004 09:14:33 +0100

I think your comments should address my concerns, were there sufficient 
changes to suggest a revised draft should be issued to the WG?

See a few comments in-line.

> Hopefully they'll make sense, but I'm sure that you'll shout if I've

<snip>

> However, I've tried to clarify the text.

Not sure I understand - the way I understood it was that an IP router 
(edge node in a DS domain) that remarks can remark the DSCP in a packte 
based on a policy - and/or on the traffic level (using a meter). If it's 
the latter, then as the traffic conditions vary, the proportion of 
remarked packets also varies...

I don't have any operational experience - so someone who has be able to 
tell us more about what they would expect. In the absence of evidence 
otherwise, I'd assume DSCP **can** change within an IP flow.

Do other people on the list have more insight?

<snip>
> 'supported' and 'optimised for'.

OK - I saw this comment to Reiner's mail.

> Worst case is to send the packet as 'uncompressed'.

Yes - I like this.

<snip>

Gorry.