Subject: RE: [rohc] FN I-D WGLC proposed way forward

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Sun, 23 Oct 2005 20:46:21 +0200

Joe,

I am fine with omotting the example altogether in the FN doc.

Note however that I do not share your opinion regarding that the example or ROHC-TCP are "violating IETF specs" with respect to the issue regarding zero IP-ID.

IMHO it is perfectly acceptable to base the design of a compression algorithm on both the specifications of protocols to be compressed, as well as observation of behavior in live networks. Actually, I think that observation is essential, because semantics of specifications do not carry all the information we need regarding how the protocol is actually implemented and behaving in practice. That we compress zero IP-ID does not mean that we encourage implementations to behave so, it only means that we acknowledge their existence. It is not up to header compression algorithms to "police" how protocols are being implemented and deployed, but rather to compress as efficiently as possible what we _expect_ will go through our compressor. And in the case of zero IP-ID, we have agreed in the WG that this is something that we expect to see. 

In addition, the support that we have for compressing zero IP-IDs comes at _no_ costs whatsoever to the compression algorithm. There is no loss of efficiency for other IP-ID behaviors.

Finally, there is already two precedents. RFC4019 (section 5.8) and RFC3843 (section 3.3) already supports compression of zero IP-IDs. So this is nothing new, and we generally like to align our profiles to each other for protocol layers that are common to each compression scheme.

/Ghyslain  

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: den 21 oktober 2005 20:09
> To: Finking, Robert
> Cc: Ghyslain Pelletier (LU/EAB); [email-masked]
> Subject: Re: [rohc] FN I-D WGLC proposed way forward
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As per my other post, I'm not sure now that the doc needs another
> example of "fields that can be all-zeroes and thus compressed better".
> 
> IMO, just omit the IPID=0 case and it would be better (in both docs -
> this and the TCP).
> 
> Finking, Robert wrote:
> > Joe,
> > 
> > If you can provide me with an example that would be great. My own
> > ability to fabricate protocols for examples is not to IETF 
> tastes (my
> > original version of the draft was criticised owing to my sandwich
> > protocol, which communicated lunch box information).
> > 
> > Thanks in advance
> > 
> > Raffles
> > 
> > 
> >>-----Original Message-----
> >>From: Joe Touch [mailto:[email-masked]] 
> >>Sent: Friday, October 21, 2005 3:29 PM
> >>To: Ghyslain Pelletier (LU/EAB)
> >>Cc: Finking, Robert; [email-masked]
> >>Subject: Re: [rohc] FN I-D WGLC proposed way forward
> >>
> >>
> >>
> >>
> >>Ghyslain Pelletier (LU/EAB) wrote:
> >>
> >>>2. Add a note that the zero IP-ID is "observed" behavior, 
> >>
> >>and that for 
> >>
> >>>header compression the choice of the behavior to assume is 
> >>
> >>entirely up 
> >>
> >>>to the profile designer - i.e. it can handle non standard 
> >>
> >>behaviour... 
> >>
> >>>but make it clear that Zero IP-IDs are actually illegal from the 
> >>>IETF's point of view.
> >>> 
> >>> 
> >>>This is in an exemple in the FN, right? I don't think you need say 
> >>>more in the FN than what the exemple is trying to achieve, 
> >>
> >>i.e. just 
> >>
> >>>have a small note that "the behavior(s) of a field can be 
> >>
> >>whatever the 
> >>
> >>>profile designer chooses, and can be based on 
> observations, and not 
> >>>only based on the protocol specifications". It should not 
> >>
> >>be guideline 
> >>
> >>>or anything, only to satisfy the curious reader looking at the 
> >>>exemple.
> >>> 
> >>>For the TCP draft, I will motivate this decision a bit 
> more clearly.
> >>
> >>It would be more useful if examples did NOT violate IETF 
> >>specs. There could be other fields that are always zero in 
> >>some cases or not in others (RED flags) which might be a 
> >>better example - in both places.
> >>
> >>Joe
> >>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDWS6sE5f5cImnZrsRAo06AJ9pvV2WE/b9aD2ndzP/ALWQ9djhggCeMAch
> kdpckmcPo+oTBP0dEyGlxdk=
> =RnHh
> -----END PGP SIGNATURE-----
> 

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 23 Oct 2005 12:26:43 -0700

Ghyslain Pelletier (LU/EAB) wrote:
> Note however that I do not share your opinion regarding that the
> example or ROHC-TCP are "violating IETF specs" with respect to the issue
> regarding zero IP-ID.
> 
> IMHO it is perfectly acceptable to base the design of a compression
> algorithm on both the specifications of protocols to be compressed, as
> well as observation of behavior in live networks.

I agree; however, with this as well as other docs, an IETF spec ought to
follow other specs. Where divergent behavior is noted, it makes sense to
note it only as:
	a) something to be avoided (e.g., RFC2525)
	b) something to be changed in the spec (e.g., RFC3655)

Now, if you want to compress "what you see", that's a separate issue. I
appreciate possible inclusion of that in the TCP spec - e.g., in a
clearly marked section about "compressing non-compliant but extant
behavior" or somesuch.

However, it's a bad idea to use that in the examples in the FN doc.

> In addition, the support that we have for compressing zero IP-IDs
> comes at _no_ costs whatsoever to the compression algorithm. There is no
> loss of efficiency for other IP-ID behaviors.

Only if you call compressing and transmitting data that should be
deleted at the destination, or may be deleted en-route 'no costs'.

While I agree that this is up there with compressing packets with bad
checksums, I wouldn't recommend compressing packets with zero checksums
all over the place even if they were seen on the wire. Same reason.

> Finally, there is already two precedents. RFC4019 (section 5.8) and
> RFC3843 (section 3.3) already supports compression of zero IP-IDs. So
> this is nothing new, and we generally like to align our profiles to each
> other for protocol layers that are common to each compression scheme.

Neither of these documents overrides RFC791 or RFC1122 on the matter.
They are examples of errors not caught by the IESG, IAB, or cross-area
review, not to be propagated, IMO.

Joe