Subject: [AVTCORE] Proposed text for draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 Apr 2011 04:36:27 -0700

Based on a comment from IESG, we would like to propose the following change to the Token draft. It is about increasing the length of the Tokens. Currently, the length field is 1 byte, IESG recommends 2 bytes with a warning sign.

Please let us know if you do not want this change. 
Link to the draft: https://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/?include_text=1

-acbegen

New text for 4.2

Token Element (Variable size): Element that is used to carry the Token generated by the server. This element is a 32-bit aligned Length-Value element. The Length field, which is 16 bits, indicates the length (in octets) of the Value field that follows the Length field. While a 16-bit length allows for Tokens with a size of up to 65535 bytes, using Tokens larger than 1000 bytes is generally a bad idea since this can easily cause IP fragmentation. Note that a Token has to be transmitted in an RTCP compound packet within a UDP packet, which often has an MTU of 1500 bytes.
 
The length does not include any padding that is required for alignment. The Value field carries the Token (or more accurately, the output of the encoding process on the server). If the Token element does not fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Apr 2011 14:02:25 +0200

Hi,

I suggest the first paragraph is changed to:

Token Element (Variable size): Element that is used to carry the Token
generated by the server. This element is a 32-bit aligned Length-Value
element. The Length field, which is 16 bits, indicates the length (in
octets) of the Value field that follows the Length field. While a 16-bit
length allows for Tokens with a size of up to 65535 bytes, using Tokens
of sizes that make the RTCP compound packet larger than the MTU might
have a negative impact on functionality because of IP fragmentation.
Some NATs or other middleboxes do not pass IP fragments, thus a large
Token can cause the whole mechanism to fail. In addition, fragmentation
increases the risk for packet loss.

Cheers

Magnus

Ali C. Begen (abegen) skrev 2011-04-14 13:36:
> Based on a comment from IESG, we would like to propose the following
> change to the Token draft. It is about increasing the length of the
> Tokens. Currently, the length field is 1 byte, IESG recommends 2
> bytes with a warning sign.
> 
> Please let us know if you do not want this change. Link to the draft:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/?include_text=1
>
>  -acbegen
> 
> New text for 4.2
> 
> Token Element (Variable size): Element that is used to carry the
> Token generated by the server. This element is a 32-bit aligned
> Length-Value element. The Length field, which is 16 bits, indicates
> the length (in octets) of the Value field that follows the Length
> field. While a 16-bit length allows for Tokens with a size of up to
> 65535 bytes, using Tokens larger than 1000 bytes is generally a bad
> idea since this can easily cause IP fragmentation. Note that a Token
> has to be transmitted in an RTCP compound packet within a UDP packet,
> which often has an MTU of 1500 bytes.
> 
> The length does not include any padding that is required for
> alignment. The Value field carries the Token (or more accurately, the
> output of the encoding process on the server). If the Token element
> does not fall on a 32-bit boundary, the last word MUST be padded to
> the boundary using further bits set to zero. 
> _______________________________________________ Audio/Video Transport
> Core Maintenance [email-masked] 
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 Apr 2011 05:04:54 -0700

Even better, thanks.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Thursday, April 14, 2011 8:02 AM
> To: [email-masked]
> Subject: Re: [AVTCORE] Proposed textfor draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01
> 
> Hi,
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]

---

From: Glen Zorn <[email-masked]>
Date: Thu, 14 Apr 2011 19:15:28 +0700

On 4/14/2011 6:36 PM, Ali C. Begen (abegen) wrote:

,,,

> While a 16-bit length allows for Tokens with a size of up to 65535
bytes, using Tokens larger than 1000 bytes is generally a bad idea since
this can easily cause IP fragmentation. Note that a Token has to be
transmitted in an RTCP compound packet within a UDP packet, which often
has an MTU of 1500 bytes.

How bad of an idea is it?  SHOULD NOT?  MUST NOT?  Whatever?

...