Subject: [BEHAVE] TURN: Handling of IP header fields

From: Philip Matthews <[email-masked]>
Date: Thu, 9 Oct 2008 13:57:40 -0400

In TURN-09, the spec defined a preferred and alternate behavior for  
how the server should set various fields in the IP header when  
relaying data. The idea was that the preferred behavior was the one we  
wanted the server to do, but some servers might not be able to do the  
preferred behavior (due to socket API restrictions or similar on a  
particular OS), in which case they should do the alternate behavior.  
Further, there was the concept of a Preserving allocation for which  
the server MUST  do the preferred behavior.

In TURN-10, as a result of the discussions in Dublin, the concept of a  
Preserving allocation was removed from the base document to allow the  
spec to advance more quickly. As part of that removal, the preferred  
behaviors were removed, and TURN-10 contains only the alternate  
behaviors.

Cullen, in a phone call to me, has objected to the removal of the  
preferred behavior. He has complained that the spec no longer allows  
his TURN server to preserve the DSCP if it can, but requires the  
server set it to Best Effort.

Cullen is suggesting that add the preferred behaviors back into the  
spec, however wording the text so that there would no longer be a  
preference between the two behaviors. For example, in the case of  
DSCP, TURN-09 said that the server SHOULD copy the DSCP if it could,  
and should only set it to Best Effort if that was not possible. Cullen  
is instead proposing that the text say that either behavior is  
acceptable and not indicate a preference.

To give you an idea what the result would be, I have included the text  
from TURN-09 below. If we went ahead with Cullen's proposal, then the  
text would no longer distinguish between the preferred and alternate  
behavior, but would describe both behaviors in the same paragraph.  
(Also note that TURN-10 removed IPv6 support, so all the IPv6-related  
stuff would not go back in).

Comments?
Do people like Cullen's suggestion?

- Philip

----------------------------
Text from TURN-09:

11.1.  IP

    This section describes the preferred and alternate behavior for
    various fields in the IP header.

    Time to Live (IPv4) or Hop Count (IPv6)

       Preferred Behavior: If the incoming value is 0, then send an ICMP
       Time Exceeded message back to the sender.  Otherwise set the
       outgoing Time to Live/Hop Count to one less than the incoming
       value.

       Alternate Behavior: Set the outgoing value to the default for
       outgoing packets.

    Diff-Serv Code Point

       Preferred Behavior: Set the outgoing value to the incoming value,
       unless the server includes a differentiated services classifier
       and marker [RFC2474].

       Alternate Behavior: Set the outgoing value to a fixed value,  
which
       by default is Best Effort unless configured otherwise.

       In both cases, if the server is immediately adjacent to a
       differentiated services classifier and marker, then DSCP MAY be
       set to any arbitrary value in the direction towards the
       classifier.

    ECN

       Preferred Behavior: Set the outgoing value to the incoming value,
       UNLESS the server is doing Active Queue Management, the incoming
       ECN field is 01 or 10, and the server wishes to indicate that
       congestion has been experienced, in which case set the outgoing
       value to 11.

       Alternate Behavior: Set the outgoing value to 00 (ECN not
       supported)

    Flow Label

       Preferred Behavior: Set the outgoing flow label to 0.

       Alternate Behavior: Same as the Preferred behavior.

    IPv4 Fragmentation

       Preferred Behavior:

          If the outgoing packet size does not exceed the outgoing  
link's
          MTU, then send the outgoing packet unfragmented.  Set the DF
          bit in the outgoing packet to the value of the DF bit in the
          incoming packet, and set the other fragmentation fields
          (Identification, MF, Fragment Offset) as appropriate for a
          packet originating from the server.

          Otherwise, if the outgoing link's MTU is exceeded and the
          incoming DF bit is 0, then fragment the packet before sending.
          Set the outgoing DF to 0, and set the other fragmentation
          fields as appropriate for fragments originated from the  
server.

          Otherwise [link MTU exceeded and incoming DF set], drop the
          outgoing packet and send an ICMP message of type 3 code 4
          ("fragmentation needed and DF set") to the sender of the
          incoming packet.

       Alternate Behavior: As described in the Preferred Behavior,  
except
       always assume the incoming DF bit is 0.

    IPv6 Fragmentation

       Preferred Behavior:

          If the incoming packet did not include a Fragmentation header
          and the outgoing packet size does not exceed the outgoing
          link's MTU, then send the outgoing packet without a
          Fragmentation header.

          If the incoming packet included a Fragment header and if the
          outgoing packet size (with a Fragmentation header included)
          does not exceed the outgoing link's MTU, then send the  
outgoing
          packet with a Fragmentation header.  Set the fields of the
          Fragmentation header as appropriate for a packet originating
          from the server.

          If the incoming packet did not include a Fragmentation header
          and the outgoing packet size exceeds the outgoing link's MTU ,
          then drop the outgoing packet and send an ICMP message of type
          2 code 0 ("Packet too big") to the sender of the incoming
          packet.  If the packet is being sent to the peer, then reduce
          the MTU reported in the ICMP message by 48 bytes to allow room
          for the overhead of a Data indication.

          Otherwise, if the link's MTU is exceeded and the incoming
          packet contained a Fragmentation header, then fragment the
          outgoing packet into fragments of no more than 1280 bytes.   
Set
          the fields of the Fragmentation header as appropriate for a
          packet originating from the server.

       Alternate Behavior: As described in the Preferred Behavior,  
except
       always assume incoming packet has a Fragmentation header.

    IPv4 Options

       Preferred Behavior: The outgoing packet is sent without any IPv4
       options.

       Alternate Behavior: Same as preferred.

    IPv6 Extention Headers

       Preferred Behavior: The outgoing packet is sent without any IPv6
       extension headers, with the exception of the Fragmentation header
       as described above

       Alternate Behavior: Same as preferred.

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 10 Oct 2008 10:25:17 +0300

> stuff would not go back in).

Well, the preferred behavior remains "preferred", right? I mean, we should 
have something like "The server SHOULD do [preferred behavior]. If this is 
not possible, the server MUST do [alternate behavior] instead."

> Do people like Cullen's suggestion?

At least I would rather we keep the both behaviors mentioned somehow.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Sat, 11 Oct 2008 12:14:45 -0400

> At least I would rather we keep the both behaviors mentioned somehow.

Cullen proposed that the spec NOT express a preference between the two  
behaviors. Not sure if this was because he felt this was the right way  
to go, or if that was just to make things easier.

- Philip

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Oct 2008 13:06:37 +0200

> to go, or if that was just to make things easier.

Personal view, but we really should express which is the preferred one.
Because I don't think there is anyone here that thinks the alternative
behavior is better if the relay have no issues with reading the
information.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Oct 2008 09:38:04 -0400

I'm OK with putting this back in (though I had previously advocated 
removal along with the rest of the preserving behaviors). However if it 
does go back, I agree it doesn't make sense to include both without 
preference. Especially since, for some of these (like ECN), I'm not sure 
there is really many other choices. So if options A and B are the only 
options, and we say you can do A or B, that is a tautology and not worth 
occupying space in the document.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave