Re: [AVTCORE] Proposed textfor draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01

Even better, thanks.

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund
> Sent: Thursday, April 14, 2011 8:02 AM
> To: avt@ietf.org
> Subject: Re: [AVTCORE] Proposed textfor draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01
> 
> 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 avt@ietf.org
> > 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt