[MMUSIC] Reply to IESG comments on draft-ietf-mmusic-sdp-bwparam

[Magnus Westerlund <[e-mail]>]

Hi Jon,

this is a message in regards to the DISCUSS the Transport independent 
SDP bandwidth parameter draft received in IESG Discussion. Below is the 
comments from the IESG and inline my reply.

>DISCUSSES AND COMMENTS:
>======================
>Steve Bellovin:
>
>Comment:
>
>There are many other things that can cause erroneous bandwidth estimates, 
>including various forms of tunneling (GRE, IPsec, 6to4) and link-layer 
>encapsulation -- should those be discussed here?
>  
>

There are many reasons for erroneous bandwidth estimates, and I think 
the draft presents some of them, but not all. The important thing is to 
establish that the problem space exist. Therefore I don't see a real 
need to discuss all of them. However as I have missed some of the stated 
ones, they should at least be mentioned. This could easily be fixed in 
an update.

>Ted Hardie:
>
>Comment:
>I found section 3.5 on the potential interaction with DCCP somewhat lacking.
>It's clear that using
>DCCP for real time media will be different in a number of ways from the 
>current flows over UDP,
>and while it is good that the draft notes the likely difference in header 
>size, it hardly seems
>like the most important thing to note.  The use of different congestion 
>control algorithms 
>seems far more salient; see draft-phelan-dccp-media-00.txt for a description 
>of how
>TFRC's "contentment penalty" might apply when wrong guesses about available 
>bandwidth 
>come into play.
>
>That section of the draft may well date back some time, of course, so it may 
>be unfair to
>ask for changes, and I certainly wouldn't block the draft for this.  But a 
>review by the DCCP
>folk might imrpove this a good bit; it also might show the need for a 
>separate draft to discuss
>the DCCP-specific interactions here.
>  
>

It is true that the section dates back a bit. However I don't think DCCP 
evolution really effects the draft at all. The reason is that the 
solution as defined does only require the one actually calculating the 
true transport dependent bandwidth to know how big the used DCCP headers 
are. And as this will depend on which options, etc. that are in use for 
each transaction. So in fact this is only one more reason to why the 
parameters are needed.

As Ted states I it is in my opinion likely that some thought at least 
will be required by the implementer to estimate the DCCP headers size 
correctly.

If I am anyway request to perform an update I could put some effort into 
improving the text in this chapter to be clearer what the problem with 
DCCP is, i.e. other fixed header size than UDP + variable size in option 
fields. It should also as pointed out mention the limitations that 
congestion control may apply on a media stream. However I think the 
important factor here is to understand that the attribute is a maximum 
that the application will use.

>Bert Wijnen:
>
>Discuss:
>From OPS Directorate review (Pekka)
>
>one potential issue I see is in the introductory section:
>
>2.2. IPv6 and IPv4
>                                                                                                                                       
>   Today there are two IP versions 4 [15] and 6 [14] used in parallel on
>   the Internet. This creates problems and there exist a number of
>   possible transition mechanisms.
>                                                                                                                                       
>                                                                                                                                       
>     ------------------            ----------------------
>     | IPv4 domain    |            | IPv6 Domain        |
>     |                | ---------| |                    |
>     | ----------     |-| NAT-PT |-|      ----------    |
>     | |Server A|     | ---------| |      |Client B|    |
>     | ----------     |            |      ----------    |
>     ------------------            ----------------------
>                                                                                                                                       
>                                                                                                                                       
>     Figure 1. Translation between IPv6 and IPv4 addresses.
>                                                                                                                                       
>                                                                                                                                       
>   -  To achieve connectivity between an IPv4 only host and an IPv6
>      only host, translation is necessary. This translator can be, for
>      example, Network Address Translation - Protocol Translation (NAT-
>      PT) [13], see Figure 1. However, to get connectivity for large
>      number of protocols, Application Level Gateway (ALG) functionality
>      is also required at the node. To be able to locate hosts through
>      the translation node DNS ALG must be supported.
>[...]
>
>==> I do not feel particularly strongly about this, but I'm not sure 
>if we want to be referring to translation and NAT-PT in a standards 
>track document like this, at least at this phase .. when it doesn't 
>seem to be necessary.  Maybe the same result could be obtained by 
>removing the figure and rewording the bullet point e.g. to:
>
>  -  The nodes which wish to communicate must share the IP version; 
>     typically this is done by deploying dual-stack nodes.  For 
>     example, an IPv4 only host cannot communicate with an IPv6 only 
>     host.
>
>  -  If communication between nodes which do not share a protocol 
>     version is required, using a translation mechanism would be 
>     required.  Work is underway to specify one for this purpose.
>
>  
>
I don't see a problem with rewording this to be less specific about the 
translation solution. It is after all only one of many reasons for this 
mechanism.


Jon, should I start working on a updated draft that address the above 
issues?


Cheers

Magnus Westerlund 

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic