TURN: Handling of IP header fields

[Philip Matthews]

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Rémi Denis-Courmont-7]

On Thursday 09 October 2008 20:57:40 ext Philip Matthews, you wrote:

> 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?

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

On Fri, 10-Oct-08, at 03:25 , Rémi Denis-Courmont wrote:

>>
>
> 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.
>

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
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Magnus Westerlund]

Philip Matthews skrev:

> On Fri, 10-Oct-08, at 03:25 , Rémi Denis-Courmont wrote:
>
>>>
>>
>> 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.
>>
>
> 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.

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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Jonathan Rosenberg]

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.

Magnus Westerlund wrote:

> Philip Matthews skrev:
>> On Fri, 10-Oct-08, at 03:25 , Rémi Denis-Courmont wrote:
>>
>>> 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.
>>>
>> 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.
>
> 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 [phone]
> Färögatan 6                | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
> ----------------------------------------------------------------------
> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave
>

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